This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Hi, I made a bean... I already separated a few attributes to lessen the amount of methods I have to make... Obviously, these are getter/setter methods. However, I kind of think it's a little unrealistic to have a class with this many methods... Are 56 methods inside a class ok? They don't do much aside from set and return a value...
It may be a sign that your bean has too much responsability. You may want to export some of the information it holds to another bean. Try to see if there is some information which you can break into different categories.
I'm talking about refactoring methods called "Extract Class" or "Extract subclass".
28 still sounds a bit too much. Think well about how you can break the information into different classes. If you feel that you can't break it anymore, then you're done.
Joined: Sep 18, 2005
I'm up to 34 methods now after adding the other classes that I've broken down as attributes to my main class. I feel like I'm digging too deep... If I refractor more... I might encounter some trouble later understanding my own methods... Or would it be the other way around?
Joined: Sep 18, 2005
ok, I've managed to strip it down again... Now I have 24 methods. Another has 22, the other ones are considerably small... I think I can't chop this down any further... Though they still seem too big...
56, 24, 38 don't really mean anything without context. If they are all getters/setters then it may be OK, it depends on whether the pieces of information make sense grouped together. If it was (for example) 5 methods with 5 versions to explose information for each class in the Collections API, that would be API bloat and be a bad thing. eg if the client using the API can convert from type A to B, don't provide methods for A and B, just B. Like wise if A extends or implements B, provide B only.
Anything more than one is quite nasty. I've called it the "2^n-1" problem that is associated with static contract inheritance - which Java implements. It implies a legitimate existence of the requirements at a fixed point in time, but catastrophic (read: contradictory) failure at any given point further along the arrow of time. I have more writing to do on this particular topic so excuse the apparent "fluff".
Timothy, what do you need all those setters and getters for? Where do they get called from?
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
I agree that the number of methods in your class doesn't matter too much as long as the methods are useful, and non-redundant. If your class NEEDS 50 methods, forcing code breakdown where it doesn't belong will only hurt the design. On the other hand, if you feel like it's too much, that could be an indication that it probably is. See if some of these properties in the bean should be read-only (no setter) or if these instance variables need be exposed to the client at all. i.e. Some properties may be sums or products of other properties or information internal to your class that the user doesn't need to know, or care about. Short and sweet there's no magic number for making a class bloated - 3 methods may be too much for one class, while 38 may be too little (i.e. a Value object for a complex business program). Getting rid of redundant properties and unnecessary setters/getters boils down to design, not class semantics.
It sounds like the ol' DTO/DXO (data transfer object/ data exchange object) pattern to me. It was stated that the methods only store and return data. Many experts say that dumb data objects are a sign of code smell. In other words all objects should have some behaviour other that storing and returning data. Without more context it is hard to determine if indeed it makes sense to have 26-50 data exchange methods. 30-50 methods all including behaviour would definitely be a sign of a class with too much responsibility. However with data it is hard to tell. For example, the data could be from 50+ form fields on an HTML page in which case a bean used to marshal the data from GET/POST encoding into the realm of Java has some value. It really depends on what you're doing with the object.
Holla at me...<br /><a href="http://codeforfun.wordpress.com" target="_blank" rel="nofollow">http://codeforfun.wordpress.com</a>
What David said above about context is true -- it's almost impossible to say anything useful with the information given.
But I will suggest that your method quantity fluctuating so dramatically might indicate that you're not fundamentally clear on the responsibilities of this class. Forget about the method count. Take a step back, look at the larger context, and identify what this class really needs to "have" and what it needs to "do." [ May 31, 2006: Message edited by: marc weber ]
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: Jul 11, 2001
Originally posted by Michael Valentino: If your class NEEDS 50 methods, forcing code breakdown where it doesn't belong will only hurt the design.
Can you provide an example for a class that NEEDS 50 methods? I can't...