Getters and Setters are bad OO design? [duplicate]

Answer 1

Getters or setters by themselves are not bad OO design.

What is bad is coding practice which includes a getter AND a setter for EVERY single member automatically, whether that getter/setter is needed or not (coupled with making members public which should not be public) - because this basically exposes class's implementation to outside world violating the information hiding/abstraction. Sometimes this is done automatically by IDE, which means such practice is significantly more widespread than it's hoped for.

Answer 2

You have missed the point. The valid, important bit of that article is:

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

Java-style getter and setter proliferation are symptoms of ignoring this advice.

Answer 3

Getters/Setters are perfectly appropriate, in the right conditions. However, mass Get/Set is wrong.

However, I'm a tad confused. You tagged Java but the material isn't really particularly Java specific (only the examples). It's worth noting that in C++ (best done in 0x) many of these issues don't exist. If you wanted to change your interface from long to int, then between decltype, templates and auto this is easily achievable, which is why such constructs rock. Typedef works well too.

Answer 4

Getters and setters are not bad by themselves. What is bad is the practice of making any field to be private and provide getters/setters for all of them no matter what.

Answer 5

From the article:

When is an accessor okay? First, as I discussed earlier, it's okay for a method to return an object in terms of an interface that the object implements because that interface isolates you from changes to the implementing class. This sort of method (that returns an interface reference) is not really a "getter" in the sense of a method that just provides access to a field. If you change the provider's internal implementation, you just change the returned object's definition to accommodate the changes. You still protect the external code that uses the object through its interface.

In other words, use interfaces for both getter and setter methods when they are necessary that way you can maintain encapsulation. It is good practice in general to specify an interface for a return type or formal parameter.

Answer 6

I'll go a bit further and say only value types should have getters. Each value type should be immutable and come with a builder which is mutable and has setters.

If your value type has setters they should return a new instance after copying the other values.

Url.setAnchor(...)

Would return a new Url copying the host port etc but overwrite the anchor.

Your service type classes don't need setters ( set them in ctor) and definitely font need getters. Your Mailer should take the host/port/etc static stuff in it's ctor. If I wish to send an email then I cell it's send(), there is no reason why my code should need to know or want or require the host and other config values. That said it would make sense to create a MailServer class like the following // value type MsilServer{ String host int port String username Strung password // all come ruth getters } // factory Mailer create( MailServer)