Software that automatically creates your getters and setters

[Anthony Smith]

I think I have heard of this. But is it true. Can I just define my members of a class and have the getters and setters generated automatically?

[Bear Bibeault]

I imagine that's a feature of a number of IDEs. The one I use, Omnicore CodeGuide has it as one of the many "refactoring" features (and even keeps the method names in synch when the property name is changed... sweet).

[Ashok Mash]

Most of the IDEs generates getters and setters, including Eclipse.

[Barry Andrews]

I created an Ant task that will create the entire source file given the types and identifiers. It saves me a lot of typing.

[Ilja Preuss]

Notice that in a good OO design, you don't have many setters or getters...

[Barry Andrews]

Huh? Can you explain?

[Jeroen Wenting]

Originally posted by Ilja Preuss:
Notice that in a good OO design, you don't have many setters or getters...

I beg to disagree...
Or do you advocate tons of public members?

In every application there are things like DTOs. Think also of beans used to send data to JSPs for tabular display.

I'd venture to say that most Objects created by the JVM in many large applications fall into this category.
They may not be the most interesting classes, or even the most numerous, but in number of instances created they surpass most if not all others except possibly String.

[Anthony Smith]

Yes. Please explain the lack of getters and setters.

[Jeanne Boyarsky]

Ilja didn't say no getters and setters. He just said not too many. A couple of reasons I can think of for this:

1) Classes should be small and focused. If your class has too many fields, it is doing too much and should be split.
2) Not all fields need to be public. If most of the behavior is on the object itself, some fields can be private/internal fields.
3) We have many DTOs as well. But they often combine smaller DTOs to build the large ones. For example a DTO might contain an address DTO. That is several fields that aren't in the main DTO.
4) Objects for tabular display often don't have that many fields (more than 6 or so) because they need to fit on a screen.

Also, I'm sure nobody is advocating public fields.

[Ilja Preuss]

Originally posted by Jeroen Wenting:
Or do you advocate tons of public members?

Quite to the contrary, I advocate that objects expose behaviour instead of data. Getters and Setters are an indicator for broken encapsulation.

In every application there are things like DTOs.

Actually in "objects without behaviour" (I'd rather call them Data Structures) I don't see how public members would do any harm.

I'd venture to say that most Objects created by the JVM in many large applications fall into this category.

I don't understand what you mean by "Objects created by the JVM" - could you please elaborate?

[Jeroen Wenting]

Originally posted by Ilja Preuss:


I don't understand what you mean by "Objects created by the JVM" - could you please elaborate?

Any object instance is created by the JVM, that's all.
You write code which tells the JVM to create an object, you don't create it yourself

[Ilja Preuss]

Originally posted by Jeroen Wenting:
Any object instance is created by the JVM, that's all.
You write code which tells the JVM to create an object, you don't create it yourself

Ah, ok...

Then I disagree. In good OO designs, most objects will communicate with other objects by asking them to do things, not by asking them for data which they will then work on themselves.

After all, that's what encapsulation is about: putting data and the operations on the data into the same entity.

[Jeroen Wenting]

In that case, do you also disagree with things like JSTL and the JavaBeans standard in general which make copious use of getters and setters?
Or DTOs which basically are objects for transferring data between parts of an application?

In an ideal world an object would never need to tell you anything about itself maybe but then you'd never know anything about it except whether what you told it to do succeeeded.

Say I have a database of user records which I query using JDBC.
Each row is stored in an object for processing.
Now would your disagree that I will want some way to retrieve the data that's stored in that record for display or use to feed data to other objects? That's what getters and setters are for after all.

Having a List of User records is nice, but if I can't get information out of it to show to the securiry guard whose duty it is to check names and access restrictions against ID cards presented by people coming into the building it's pretty useless.
Or maybe the User record can do that verification, but if it can't get the data from the ID card record because that one has no getters it's blind as well as mute and deaf.

[Ilja Preuss]

Originally posted by Jeroen Wenting:
In that case, do you also disagree with things like JSTL and the JavaBeans standard in general which make copious use of getters and setters?

Don't know much about JSTL, sorry. JavaBeans probably have their uses, but I wouldn't like them to be at the heart of my application, no.

Or DTOs which basically are objects for transferring data between parts of an application?

As I said, I don't think that DTOs actually quallify as objects and wouldn't even care if they had public fields.

In an ideal world an object would never need to tell you anything about itself maybe

I wasn't talking about an ideal world, and I wasn't talking about never using any getters or setters.

What I am talking about is pragmatic considerations. To build maintainable and extendable applications, we need to manage the dependencies between objects. Encapsulation, that is putting operations close to the data they are working on, helps decoupling objects from one another. Getters and setters basically allow objects to operate on data of other objects, and therefore break encapsulation. Therefore it's a good idea to think twice before introducing them and to not have many of them.

Say I have a database of user records which I query using JDBC.
Each row is stored in an object for processing.
Now would your disagree that I will want some way to retrieve the data that's stored in that record for display or use to feed data to other objects? That's what getters and setters are for after all.

I feel that getters used to display data are a petty evil.

Regarding feeding data to other objects, I would need more details to decide.

Or maybe the User record can do that verification, but if it can't get the data from the ID card record because that one has no getters it's blind as well as mute and deaf.

Perhaps the user record could ask the id card wether it matches its information? Think "objects that interact" instead of "dumb data records"...

http://c2.com/cgi/wiki?TellDontAsk

[Warren Dew]

Ilja Preuss:

Don't know much about JSTL, sorry. JavaBeans probably have their uses, but I wouldn't like them to be at the heart of my application, no.

I haven't used JSTL yet, but I've used JavaBeans in a web context. In my opinion, the need for lots of getters and setters in this context is caused by the fact that HTML is not an object oriented language. That means JSPs can't really be object oriented, and all the getters and setters basically provide a way for this procedural language to access the stuff being done in the actual Java code.

Within the Java code, I'd regard a large number of simple accessors and mutators as a sign that the code isn't very object oriented. I wouldn't mind a few functions starting with "get" - factory functions, for example - but in general even those ought to do more than just provide simple access to a field.

[Jeff Langr]

What Ilja is getting at is that you don't want to center the design of an OO application around a bunch of data structures (aka ADTs/abstract data types). The core concept of OO is sending a message to an object, then letting it go off and do its work. As a message sender, you don't care how the object does its work or what data of its own it uses to accomplish the task.

A useful phrase is "tell don't ask." Prefer telling an object to do something based on its own data, instead of asking it for various pieces of data and then doing the work yourself. (Obviously we'll always need the ability to extract data from objects, perhaps to display or verify. But those needs shouldn't be the focal point of the OO design.)

-J-
[ July 06, 2004: Message edited by: Jeff Langr ]