Getter and Setter vs. Builder strategy

Question

I was reading a JavaWorld's article on Getter and Setter where the basic premise is that getters expose internal content of an object, hence tightening coupling, and go on to provide examples using builder objects.

I was rather leery of abolishing getter/setter but on second reading of the article, see to quite like the idea. However, sometimes I just need one cruical element of an entity class, such as the user's id and writing one whole class just to extract that cruical element seems like overkill. It also implies that for different view, a different type of importer/exporter must be implemented (or the whole data of the class to be exported out, thus resulting in waste).

Usually I tend towards filtering the result of a getter - for example, if I need to output the price of a product in different currency, I would code it as:

return CurrencyOutput::convertTo($product->price(), 'USD');

This is with the understanding that the raw output of a getter is not necessary the final result to be pushed onto a screen or a database.

Is getter/setter really as bad as it is protrayed to be? When should one adopt a builder strategy, or a 'get the result and filter it' approach? How do you avoid having a class needing to know about every other objects if you are not using getter/setter?

Answer 1

The argument that getters and setters unnecessarily expose "internal" properties of an object is only true if the exposed properties are, in fact, internal. Getters and setters are just fine if they expose data that you want to be exposed as part of the class's public interface.

For example, it's OK for a 2-D Point class to have getters/setters for X and Y. Otherwise, how else could you make use of it?

On a side-note, though, some schools of thought discourage setters, preferring immutable classes where all properties are set in the constructor.

Answer 2

I tend towards avoiding setters. I also avoid getters in many circumstances. I prefer to follow the maxim that you should tell objects what to do for you, not do things for them. If you pull data out of the object and then perform work on that combination of data, then that looks to me like the object should be doing the work itself. I have no problems with getters returning data for output etc., and as always pragmatism wins out.

Immutable classes (those without setters) are preferred in some circumstances, due to the benefits in threaded environments. The object won't change under you. I tend towards immutable object for this reason and those highlighted in the first paragraph.

How do you change these objects ? By creating a new one using the original as an input to a constructor, together with the differing data. Again, you have to be careful with this. If the object is sizeable then this is not a pragmatic approach.