Re: The Accessor Heresy

[lhoward]

My problem with this approach is the disregard for the Law of Demeter. In short: Only talk to your immediate friends.

The Law of Demeter is intended to encourage shy, decoupled code (Pragmatic Programmer p.138) to promote maintainability & adaptability. Without the Law of Demeter, objects depend more on the internal structure of other objects. The trade off is that you end up writing more accessor methods.

In this example, if Circle::Radius or Circle::Area were changed (or replaced by other objects) interface compatibility must be maintained, not only for Circle but for all the other code that works with Circle objects. If the Circle::Radius & Circle::Area objects are accessed through accessor methods of Circle, then their interface details are hidden from any users of the Circle class.

Of coruse, any tenet of programming if taken too far leads to horrible code.

L

[Roy Johnson]

The reason the Circle::Radius object exists is that it is part of the Circle object model. It is not an implementation detail, any more than Circle itself is. It is the portion of the Circle public interface that deals with radius-related property fiddling. Instead of embedding the name of a property in the method name, you would have an object by that name that has a simple method name. For example, you prefer:

$myCircle->operate_on_Radius;

Inherent in that name is the fact that there is a Radius property, a sort of implicit object. All else being equal, I would prefer to see

$myCircle->Radius->operate;

If either of us got rid of the concept of Radius, we would have to change our API. There is no benefit of either API over the other as far as that goes. If you change the object model, you have to change the API. Because the API is supposed to reflect the object model.