On Rigid Rules

David Buck had some excellent thoughts on hard and fast rules in com.lang.smalltalk concerning the often hotly debated "getters/setters" argument:

Rules like "don't write getter and setter methods" are off the mark.
The problem is not getters and setters. The problem is coupling and distribution of knowledge. The fear is that if you have getters and setters on an object, then other objects are going to extract the private data of the object, do some processing on it and write it back. This operation increases the coupling between the two objects and
leads to a poorer design.

When it comes right down to it, there is basically one problem that object oriented programming tries to solve: rigidity. Rigidity occurs when a small change in the design requires significant changes to the code. For example, if you decide to rename an instance variable, any method that uses that instance variable needs to be modified. If you need to add a parameter to a method, any other method that calls it
needs to be modified in order to pass in an extra parameter.

What we want is what I call "Local Change, Local Effect". This means that a change in one area only affects a small amount of code in that area and doesn't cause massive changes and propagation of changes.

Back to getters and setters. The getters and setters on their own aren't a problem. It's how and why they are called that can cause problems. If other objects are calling getters and setters then doing work on the result, it's likely that many objects need to do the same work. This results in duplicated code. Duplicated code causes rigidity. Any design change that affects this code will affect all
copies requiring changes to be made across the system. It's better to have one copy of the code performing this operation and the natural place to put that code is in the original object.

Having said that, there are many cases where instance variables of an object are fundamental to the object's behavior and you need to be able to set them or get them. Just have a look at why you are getting or setting the variable. If it leads to duplicated code or distribution of knowledge, you are introducing more rigidity.

I have found myself in the dreaded "getter/setter" debate and I refuse to debate it anymore. David's reply above is eloquent and gets to the heart of the matter: good design. "Getters/setters" is not seeing the forest for the trees. Read the entire thread. It's a lot of fun and everyone made great points.