Meaningless Drivel is fun!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Bad design to have JavaBeans with many attributes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Bad design to have JavaBeans with many attributes?" Watch "Bad design to have JavaBeans with many attributes?" New topic
Author

Bad design to have JavaBeans with many attributes?

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi rangers,

I'd like to hear your opinion what's the best way to handle JavaBeans for entities which provide lots of attributes. It simply doesn't feel right to have beans with 10, 15 or 20 attributes together with all the necessary getter and setter methods and perhaps additional validation methods and listener handling.

How do you think about this? Do you think it's OK to have such big JavaBeans if all attributes really belong to the entity the bean stands for? Or would you say it's better to split the information in some logical way and compose a "super bean" out of other smaller beans? I'm even thinking about some lookup concept which maps property names to property values (objects) like for example the NetBeans lookup mechanism does.

What is your experience with the design or pattern to use in case of such entities with (too) many attributes regarding extensibility or maintainability?

I'd be glad if some of you could share their ideas with me!

Marco
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30057
    
149

Marco,
Often there are sub-entities hiding within the bean. Do you have an example of a huge entity that we could discuss here?


[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
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hello Jeanne,

this is exactly what I've been thinking about too. And indeed there some information which I could extract into sub-beans. In this case the application is just for private use but I often faced similar problems in other applications.

I'd like to have a simple application which allows me to store all the information my bicycle computer gathers during a ride. I could list all these information here but I think you wouldn't want to know really all the details In short there are some values concerning the time, speed and distance, others for altitude data, some pulse information and even temperature data. Usually there is more than one value to each of these data pieces like a maximum, minimum or average value. I think the grouping of the information above could already form the logical boundaries where I could break up the whole thing into smaller sub-beans.

As I said this is just an example for the problem. I even have an idea where I could divide the data into smaller beans. I'm just not sure which way is better regarding good OOP design, extensibility and maintainability. From a practical view all the data correspond to one bicycle ride. So I consider all data values attributes of one ride (bean). On the other hand as described above I can logically group most of the information and use these groups to create smaller sub-beans.

How do you decide when or if you should split such data classes into smaller chunks? From a design perspective it doesn't feel right to have objects with too many attributes but maintaining a bunch of classes instead may be more laborious. Because this application is only for personal use I could simply try both ways but I'd nonetheless I'd like to hear your opinions on that.

Marco
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

This is a great question to raise here on Javaranch!

Generally speaking you should always try to split things into logical sub component parts, the problem always being what is the 'logical' split. The answer to this is..... there is no right answer

If you got 5 OO gurus in a room together you'll find that they would split your bicycle problem into completely different logical groupings.

The only extra hint I can give is (_without_ going too far down the pre-optimization path) is to think about how discrete parts of that data could be used outside of your bicycle application, perhaps in a jogging application...


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860
In short there are some values concerning the time, speed and distance, others for altitude data, some pulse information and even temperature data. Usually there is more than one value to each of these data pieces like a maximum, minimum or average value.

My initial impression is that you should have a BikeRide class that contains many Metrics classes. Below I am assuming all metrics have the same type and number of properties, which may not be the case. If behaviour or properties are different you may want to use Metric as your base class, but the principal still applies.



I usually find that once I have an object like the one above I want to have some collection of a group of them. Say all the bike trips you went on in a week. A good way to model this is the Composite gang of 4 design pattern.



http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Just to add to the conversation, I work with a Hibernate-driven Javabean that has 103 fields. Everything works fine and there are no problems with performance. There is no need to change anything here.

The number of fields of a JavaBean should be determined by business requirements, not technical design opinions, in my opinion. A software design should be dependent upon business/domain requirements, not the other way around.

The most important thing about a software application is "what" it does, not "how" it does it.
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Originally posted by James Clark:
Just to add to the conversation, I work with a Hibernate-driven Javabean that has 103 fields. Everything works fine and there are no problems with performance. There is no need to change anything here.

The number of fields of a JavaBean should be determined by business requirements, not technical design opinions, in my opinion. A software design should be dependent upon business/domain requirements, not the other way around.

The most important thing about a software application is "what" it does, not "how" it does it.


In terms of 'accurately modeling' a domain object I have to agree with James here, if the real world object has ~20 attributes/metrics then it is 'correct' to model that as one class with 20 attributes/fields. Splitting _that_ into smaller objects for say viewing subsets of metrics is then perfectly valid.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi folks,

I'm really glad and surprised to read all your valuable comments here. First I was unsure if this problem was too trivial to get some answers or advices. But it seems that I'm not the only one who is concerned with this modeling and design issue.

Thanks a lot for all your answers! What I can see from all your answers is that "it depends" how a good solution may look like Of course that's definitely what I'd always expect when it comes to design decisions and every comment from you really gives very helpful advices how to design such an application I described. In fact this motivates me to give all the different proposals a try and to evaluate in-depth what the advantages or disadvantages of each solution are. Perhaps I should have done this earlier but I guess the ranch is always a good place for this kind of discussions

Marco
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860

The number of fields of a JavaBean should be determined by business requirements, not technical design opinions, in my opinion. A software design should be dependent upon business/domain requirements, not the other way around.


I agree. However, in this case the posters requirements point more towards having an Object instead of simple fields. This is because each metric has values for min, max, average, total etc. By modelling this as seperate methods it would look something like the following method names:


If each of distance, altitude, speed etc only had one value then a single Java class would certainly be appropriate though.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Introducing such a Metric class seems to be a really good idea and absolutely makes sense in this case!

But I have to agree too that in my opinion it's OK to have some more attributes in a bean for the sake of reduced complexity of the code when this complexity wouldn't gain any advantages.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bad design to have JavaBeans with many attributes?
 
Similar Threads
EJB or not ?
EJB entity beans with both local and remote interface
ejb using datasource best practice
EJB (CMP) performance ... why so slow?
help ..