October, 2006


31
Oct 06

Yet another accessors/mutators discussion

In the last few months I followed and participated in numerous discussions about getters and setters.  From the topic popping up in various discussions on framework design, OOD, domain models, and the popular (if not in the number of readers, at least in the number of critics:-) article from Allen Holub about why getters and setters are evil.

Of course the programmers that have designed numerous applications/frameworks that participate in what to me is procedural programming with OO idioms, will be very defensive (it’s human nature).  I used to use accessors blindly as well, since it was easy and made sense.  Hey, we’re still encapsulating right?  Access to the field is now behind a method call, so the implementation is not as tied to a particular state field.  That’s a load of crap and I wish folks would truly stop defending such horrific practices.

In no way am I saying that access to all internal state is bad, but access should reflect a meaningful business method, not simply retrieving an internal implementation detail.  Yes, in some trivial apps in might not make sense and in others it might increase the amount of code drastically, but that’s relative to someone having to read the loads procedural crap in the future with all the object messages being passed around all over the place.  Good OO design principles are all about encapsulating the state, though limiting the amount of messages flowing through the system.

I mean, if I have something to say and I can speak, I’d rather say it myself thank you, rather than have someone query me about what’s on my mind and say it for me.  It’s just basic design principles.

Now, today, yet another thread on TSS brings up the topic of reducing the amount of typing people have to do while generating getters/setters.  How about reducing the amount of getters/setters?  Have anyone though of that before?  It’s like EJBs (pre-3.0) all over again.  Let’s create code generators to generate a bunch of stubs vs. actually fixing what’s wrong with the design to begin with.

Well, nothing unusual about the thread, other than David Bernard pointing us to a link that states…

"I keep my code cleaner and clearer. : Use public attribute as property, instead of private attribute and accessor methods."

What?  This can’t be true.  So we now take the horrific practice of exposing state, but at least through accessor methods, which makes us less implementation dependent [as the method implementation can be changed without effecting the signature and return type] and replacing it with public access to internal attributes?  Wow, I’d really love to see a non-trivial app build that way.  Actually, no, I would love to fly to the future and meat the person that has to maintain and extend the app in the future.  Poor soul.

Ilya Sterin