[Tutor] designing POOP

[Kent Johnson]

Alan Gauld wrote:

> Over-use of direct access tends, in my experience, to lead to
> the temptation to move code that should be in the class (or a
> subclass) into client code. And it is avoidance of that temptation
> that is my main reason for providing a values() or state() type
> method, rather than using multiple attribute access.

I agree that it is easy to write code in a client, using attribute 
access, that really should be in the class as a method. I'm not sure how 
providing a value() method prevents that, other than making the client 
code more awkward.

In either case the solution is to recognize the code smell (Feature Envy 
or Inappropriate Intimacy) and refactor to fix the problem.

> The secondary reason is that a class author should be free
> to change the internal data of a class provided he doesn't change
> the message interface, but allowing direct access greatly increases
> the risk that a change will break some users code. Particularly
> if the change involves removing an attribute or converting it to a
> derived value.

That is the usual argument for getters and setters in Java and C++ (at 
least). It makes sense for those languages but it doesn't hold water in 
Python where a simple attribute can be changed to a property with 
whatever underlying functionality you like and no change in client code.