Letters to the Editor

JavaWorld.com, 09/26/03

Java Toolbox
"Why Getter and Setter Methods are Evil"
Allen Holub

LETTER_HEAD: Accessors and XML

Allen,

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

AUTHOR_REPLY:

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 END_REPLY

LETTER_HEAD: UI-layer abstraction

Allen,

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

AUTHOR_REPLY:

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

END_REPLY

LETTER_HEAD: Database records

Allen,

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.