You’re correct. I was thinking back to early versions of Hibernate and Spring where this was necessary. In point of fact, you can dispense with getters and setters for the most part, making their use even less forgivable. They are, as far as I’m concerned, a code smell akin to stuffing everything into one main() method.

First, in languages that support interfaces, put all of the getter/setter methods in an interface, then only use that interface in system boundary contexts.

Second, practice good OO. Don’t pass primitive types (other than booleans) around as parameters and return values.

Third, for those cases where you do need implementation details, such as computing aggregate values from a collection of objects, make sure the circle of collaborating objects that have this tight coupling is specific and small. The moment it gets larger, you have a refactor on your hands.

What alternative to getters and setters do you recommend? Non-private member variables (laughing)?

@MoffDub – very insightful post. Too bad it’s a lot of work to do this. I would recommend only doing this for client/module/library APIs that will be called by an unknown set of users.

Can you be more specific? You love the getters and setters?

Anyway, here’s the conclusion I most recently came to on this. The catch phrase shouldn’t be “getters and setters are evil”, but rather “revealing internal implementation details and enabling procedural-style programming is evil.”

If you are practicing something like domain-driven design, then I see nothing particularly evil about having getters for the fields of a domain object, as long as you encapsulate those values into an object. Also, these fields need to be domain-relevant fields, which they all should be if you are really keeping the domain model clean.

For instance, instead of having the Customer object’s getID() return and int or a long or whatever it is, return a CustomerID object. Any logic you need to perform with it, like comparison, should be methods of CustomerID.

Similarly, when you need the actual value for the UI or persistence, say CustomerID.asString(). This way, if the internal implementation of CustomerID changes from int to long, no other class is affected.

Some other words on this: you should also probably return copies of such objects for these getters, unless you can absolutely guarantee that the objects returned are immutable. If not, then changing the returned object can muck with the containing object’s implementation in a way inconsistent with its API.

Another thing is I think setters for every fields ARE in fact evil. If you have getters for every field, and setters for every field, you have devolved, as you pointed out, to procedural programming. Setters are fine if they make sense for the object (i.e. the requirement is that customers can move to a new address, so Customer.setAddress(“123 Main Street”) ). The setters for fields that are only set once need to be one-time only… in other words, use a constructor.

They can be used in certain contexts, but only as part of an interface whose use is restricted.

Or are you saying they simply should not be used to expose all the internals of a class?