Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:
JavaWorld.com > Java Standard Edition >

Letters to the Editor

JavaWorld.com, 09/26/03

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

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

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

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



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

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



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.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources