Java Toolbox

"Why Getter and Setter Methods are Evil"

Allen Holub

Accessors and XML


Getters and setters, unfortunately, are a tragic reality when designing classes used with XML serializers. The deserializers are bean-style and first invoke a no-arg constructor and then use all the setters. Does this fall into the Border Interface area, as you mentioned with Java Database Connectivity (JDBC)? Doesn't it seem like XML (de)serializers could work without the getters and setters?

This forces astute designers to façade their XML-capable objects. This might be a good topic for another "is evil" article. I'd love to hear your suggestions in this area.

Jed Reynolds

Jed, Yes, I know. There was a Sun Microsystems presentation about XML serialization at the SDForum Java SIG a couple of years ago, but there was no interest in my argument. On the plus side, the new metatdata feature scheduled for the Java 1.5 release next year could, at least in theory, solve the problem. That is, you could say something like:

   public @xmlSerializable Type data;

and dispense with the get/set idiom entirely. Let's hope for the best. Allen Holub

UI-layer abstraction


I'm one of those "new OOP designers" mentioned in the article, and I don't understand how to abstract the user interface (UI) layer and at the same time eliminate 99 percent of the getters and setters. Where I can obtain this information?

We are transitioning from legacy two-tier systems written in Delphi to Java. The new system is required to use rich graphical user interface and Web browser views so this subject matter is important to us.

Getters and setters are actually part of the language specification in Delphi.

Cody Skidmore

Cody, You can't really abstract the get/set methods out of the UI-construction layer (Swing, etc.), simply because, at this level, the classes have to be extremely generic. Instead, you should think about how to encapsulate the UI-construction layer inside the higher-level classes. Depending on where you are in the transition process, you may be able to add the encapsulation to the new system. The main thing is the new system's designers must really know what they're doing (or get some outside help with the design). I've done design reviews for this sort of project many times, and I've often found that the new system is not significantly better than the old one; it's just different. Allen Holub

Database records


I'm working on a relatively large project that involves database access and users editing the database records. I'm having trouble applying your concepts to my program. I have objects (classes) that represent signed-on users, each type of record in the tables, and in some cases a representation of several records in related tables combined into one object. Many of them share information with each other, but I still have getters and setters. How do I apply this concept when users need to access and edit the records' various fields? I'm open to any idea that can improve my programming skills.

Scott Reynolds

Scott, The problem is that you're looking at things from a database-centric perspective rather than from a domain-centric perspective. In CRC (classes, responsibilities, collaboration) modeling, for example, you need to keep the conversation in the problem domain, using the vocabulary and processes that real users would use. This way the messaging system reflects the domain directly. The database is just used by some of the classes as a persistence mechanism, and won't appear in the initial model at all. Looked at another way, a database is a fundamentally procedural element. It's just a big bag of data. Consequently, it's impossible to access it in an OO way. You should encapsulate the procedural calls to the database into objects, however, and then write your code in terms of the interfaces to these encapsulating objects. Inside the encapsulating objects, you'll be doing what amounts to get/set calls on the objects. Most of the program won't see this work, however, because they'll be interacting with the higher-level encapsulating object, not the database. Allen Holub

Clear the litter


I was motivated to write to you after reading many of the responses to this (great) article.

First (and this is just personal opinion), I think programming is a lot like art or cooking. If you think you do it well, it's easy to become defensive when people make suggestions or offer new approaches. I think this is the cause of a lot of the negative feedback to your article.

I, as a programmer, fall into the guilty as charged category. I have found that over the last year, my code has become more and more littered with accessors. Accessors have increased the complexity of my code and generally make quite a mess of things. In my case, the problem is exacerbated by currently available (IDE) tools that make accessor generation/maintenance a breeze and refactoring a snap. When refactoring is able to update 30 classes impacted by a change in an attribute, it's too easy to overlook the problem you've created.

Please do not take the criticism too much to heart. I, like many others I assure you, look forward to your future articles.

Donald Kittle