TITLE: the case for accessors

(Newsgroups: comp.lang.c++, 2 Jun 97)

[ A frequent class design issue concerns accessors, those pesky
  get/set methods used to access data members. Designers new to
  the business of abstraction populate their classes with a get
  and set method for EACH data member; this practice is widely
  recognized as inferior in design. In reaction to this, some
  designers insist on having NO accessors. Most, including Robert
  Martin below, agree that the middle ground is more realistic. 
  -adc ]


RIEL: Arthur Riel

> A more important question concerning the point class is, "Why are you
> taking
> the values of x and y away from the class and what are you doing with
> them?  Why doesn't the class which owns the data do it for you?".


MARTIN: "Robert C. Martin" <rmartin@oma.com>

Valid questions.  But their answers don't always imply that accessors
should not be used.  For example, I'd like to construct the four line
segments that define the rectagular boundary that surrounds two points.
I could ask the points to do this for me:

    vector<LineSegment*> Point::MakeBoundary(const Point&);

However, my point class is reusable in many applications that 
don't need this feature. Must I now recompile all those other 
applications just so that they can remain up-to-date with the new
Point class?  Anyway, I just don't want my Point class knowing
about the concept of rectangular boundaries....

A better structure is probably:

           class Boundary
           {
             public:
               Boundary(const Point&, const Point&);
             private:
               LineSegment sides[4];
           };

But I'll need accessors in class Point to do this.

I agree with you, accessors are structures to be suspicious of, 
but sometimes they are the proper approach.