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. _______________________________________________ Tutor maillist - [email protected] http://mail.python.org/mailman/listinfo/tutor
