aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes Software that automatically creates your getters and setters Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Software that automatically creates your getters and setters" Watch "Software that automatically creates your getters and setters" New topic
Author

Software that automatically creates your getters and setters

Anthony Smith
Ranch Hand

Joined: Sep 10, 2001
Posts: 285
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60077
    
  65

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).


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ashok Mash
Ranch Hand

Joined: Oct 13, 2000
Posts: 1936
Most of the IDEs generates getters and setters, including Eclipse.


[ flickr ]
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Notice that in a good OO design, you don't have many setters or getters...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

Huh? Can you explain?
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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.


42
Anthony Smith
Ranch Hand

Joined: Sep 10, 2001
Posts: 285
Yes. Please explain the lack of getters and setters.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29287
    
140

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    1
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
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
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 ]

Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Software that automatically creates your getters and setters
 
Similar Threads
Importance of complete Javadoc
jdbc and nearly global variables question
Getter and setter in part2
Why Groovy?
using c:forEach to iterate over Map<String, ArrayList<Hashmap>>