in reply to Re^2: The Accessor Heresy
in thread The Accessor Heresy

I didn't explain myself well enough. The point is that accessors are poor design - they are telling you that you haven't sufficiently thought through the interface.

Let's put it another way: If you expose your attributes through the use of accessors, you have coupled your client to your implementation. Yes, you can have fake accessors like your Area accessor, and that can be a powerful tool. But, I think it's a poor way to have people think about your object.

I strongly urge you to take a look at Ruby's Array, Hash, String, and File classes. That is the standard I am now holding myself to when it comes to class design.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^4: The Accessor Heresy
by Roy Johnson (Monsignor) on Nov 28, 2005 at 19:34 UTC
    They are not "fake accessors", they are object-oriented accessors, as opposed to the usual method-oriented accessors (neither of which couples the interface to the implementation). Properties of an object are a legitimate part of the object model, not merely part of its implementation. They are conceptual objects. Method-oriented design (where the object name is embedded in the name of a parent object's method, or is passed to it) sweeps that under the rug. There is reason to do that; I'm not saying it shouldn't be done. I just think people should be aware of why it's done. Because it rankles.

    Accessors certainly can indicate poor design, but they don't always. Some objects are intended to be freely manipulated. The objects in a drawing program, for example. Or the accounting books at Enron. The object has to model the process, it can't dictate it.

    Caution: Contents may have been coded under pressure.
[reply]

In Section Meditations