• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

56 methods, is this realistic?

 
Timothy Sam
Ranch Hand
Posts: 751
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
Timothy Sam
Ranch Hand
Posts: 751
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok... Now I've managed to strip it down to 28 methods... Is this ok now? I can't show any code right now since I'm doing everything on paper...
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Timothy Sam
Ranch Hand
Posts: 751
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Timothy Sam
Ranch Hand
Posts: 751
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Moving to Java in general (intermediate).
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Timothy, what do you need all those setters and getters for? Where do they get called from?
 
Michael Valentino
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Clifton Craig
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:

Can you provide an example for a class that NEEDS 50 methods? I can't...


How many methods does JComponent have?
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


Can you provide an example for a class that NEEDS 50 methods? I can't...


Can you provide an example for any contract where there is a need for more than one operation?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic