More on “More on getters and setters”

Allen Holub wrote an article in Javaworld recently entitled More on getters and setters Oh boy, has this article caused some fuss in places.

think what a lot of objections have come about because people don’t really understand Holub’s point. In particular, they don’t understand why accessors and mutators are bad for domain objects. The reason, particularly for mutators, is that it violates encapsulation.

Holub isn’t really saying that people shouldn’t use getters and setters, where appropriate. Nor is he just down on the names; after all, you can take the Exporter and Importer interfaces he supplies, and replace “add” with “set” and “provides” with get. (I think he used different verbs for a point, myself) Indeed, if you were to use his pattern, I would strongly encourage the use of the standard verbs, as it ties in with the JavaBeans idiom a lot better.

No, the problem is that you shouldn’t use accessors and mutators on domain objects because you lose control. This is more true of mutators than accessors, but it holds for both. If you expose fine-grained access to mutators in your domain objects (e.g. setName(), setAge(), setAddress()…) you also expose the interrelationships between the properties. This is a “Bad Thing”, in general, because it means that the client code has far more opportunties to stuff up your domain objects. Accessors are bad as well, but not to the same degree; the most likely problem would be performance (at least as far as I can see).

In general, getting your domain objects to populate and retrieve from your view objects is a good idea, because it helps to limit dependencies and validation. It also means that your domain object can validate the data it is given in advance, before it starts changing itself; this is good and allows for more “atomic-like” updates. You can also turn this very easily into a Unit of Work implementation, by chaining copies of the importers and exporters so that you know what was done to the domain object. Heck, you can even use this pattern to provide “undo” functionality!

A final point to make here is that this is an extension of the well known Data Transfer Object pattern. Consider the following, based on the Employee example from Holub’s article:

public class EmployeeDTO implements Employee.Importer, Employee.Exporter {
  public void addName(String name) { ... }
  public String provideName() { ... }
  public void addID(String id) { ... }
  public String provideID() { ... }
  public void addSalary(String salary) { ... }
  public void provideSalary() { ... }
  public void open() { ... }
  public void close() { ... }
}

So anybody who is using DTOs to fetch data from the Domain Object or to update them is already using this pattern (albeit in a simplified form).

Nobody is saying that you shouldn’t use getters and setters where appropriate. Particularly appropriate places are UI layers and DB layers, where the use of property-based reflection is especially common. But your domain objects are a high-order species, and have different rules.

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down. View all posts by Robert Watkins