Home arrow static arrow Java Programming [Archive] - too many methods
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - too many methods
This topic has 16 replies on 2 pages.    1 | 2 | Next »

Posts:52
Registered: 7/6/04
too many methods  
Jul 19, 2004 12:09 PM



 
i always wondered how can other people have so many classes in their program but i just have very few, in last project someone else have 50 classes whereas i just have 10.

i am writing a shell program that have about 20 operations user can perform, but there are much more public methods (probably 50), which means it is a 3000 lines code, is this too much? can i do them seperately in different classes? i guess i may use Vistor pattern but do anyone know better or easier solutions?

many thanks!
 

Posts:18,384
Registered: 21.03.00
Re: too many methods  
Jul 19, 2004 12:12 PM (reply 1 of 16)



 
Hi,

It's all about design. One class should only do one thing. And if you have one class with more than 1000 lines you have to re think your design.
There is no specific design pattern that solves this problem. Just think about repsonsibilities.

/Kaj
 

Posts:21,719
Registered: 98-02-20
Re: too many methods  
Jul 19, 2004 12:16 PM (reply 2 of 16)



 
Good design is a matter of taste, style, and experience.

A class should be cohesive and complete. It should represent a solid abstraction that models your problem well.

I'd worry that perhaps you hadn't abstracted your problem well enough. You don't mention interfaces. Do you ever design to an interface? You mention Visitor, a good sign. Do you use GoF Design Patterns much? Know much about anti-patterns? Ever heard of the Winnebago anti-pattern?

If your shell class has 20 public methods that are intended for users, and the other 30 methods are helpers that are called by your class, perhaps you could split those methods out into package-visible classes. But it's impossible to tell without seeing code and hearing more about the problem.

Do you get to look at those other designs that used 50 classes to your 10? What did you think of the comparison? Which one would be easier to extend?

%
 

Posts:37,103
Registered: 3/30/99
Re: too many methods  
Jul 19, 2004 12:21 PM (reply 3 of 16)



 
I'd also recommend Fowler's refactoring book, and any tutorials you can find on the topic. Putting too much into one class or one method is a common mistake for newbies (and unfortunately for those with a fair amount of experience too).

See if your code has some of the symptoms that Fowler discusses. It may be that your design is fine the way it is--as somebody said, we can't tell without seeing it--but if you have one class with 50 public methods and 3000 lines of code, it's almost guaranteed that it could stand to be chopped up.
 

Posts:52
Registered: 7/6/04
Re: too many methods  
Jul 19, 2004 3:45 PM (reply 4 of 16)



 
many thanks for all these replyes, i always consider a class as an object but never think that a class can be a method. my shell program has the following operations:
0.  open a database.1.  close this database.2.  create a new database.3.  create a relation.4.  configure a relation.5.  add records in a relation.6.  delete records in a relation.7.  update records in a relation.8.  compute union of two relations.9.  compute intersection of two relations.10. compute difference of two relations.11. compute cross-product of two relations.12. rename a relation.13. select records from a relation.14. project columns from a relation.15. join two relations.16. divide two relations.17. save a relation.18. delete a relation.19. print a relation.20. save this database to disk.21. read the database from disk.

i implement them all in a class called shell, just wasnot sure how to seperate them.
 

Posts:37,103
Registered: 3/30/99
Re: too many methods  
Jul 19, 2004 3:57 PM (reply 5 of 16)



 
many thanks for all these replyes, i always consider a
class as an object but never think that a class can be
a method.

I wouldn't say a class is an object or is a method. A class defines what an object (an instance of that class) can do, and how it does it. An object has state (its fields) and behavior (its methods).

my shell program has the following
operations:
0.  open a database.1.  close this database.2.  create a new database.3.  create a relation.4.  configure a relation.5.  add records in a relation.6.  delete records in a relation.7.  update records in a relation.8.  compute union of two relations.9.  compute intersection of two relations.10. compute difference of two relations.11. compute cross-product of two relations.12. rename a relation.13. select records from a relation.14. project columns from a relation.15. join two relations.16. divide two relations.17. save a relation.18. delete a relation.19. print a relation.20. save this database to disk.21. read the database from disk.

i implement them all in a class called shell, just
wasnot sure how to seperate them.

At first glance, that seems like too much to put in one class. That's a package or library or application, but just the number of operations alone looks like it's worth breaking it up into smaller classes.

Then looking at what the operations are suggests what the breakdown should be.

For instance 20 & 21 might be a class by themselves--DBIO. Or maybe two classes--DBWriter and DBReader. Those two classes could then be in a package called whatever.io. (Not literally "whatever" of course.)

Union, intersection, difference, crossproduct might each be in their own class in an "operation" or "math" package, or maybe they'd be in a single class. Either way, they don't belong in the same class as the writer & reader, IMHO.

Those are just rough ideas, and without me knowing more about your overall shell project, I can't give good, detailed advice. The main thing is think smaller--one class should do one thing, or a few very closely related things.

Seriously, check out Fowler's refactoring book. The concepts are invaluable, and he presents them well.
 

Posts:324
Registered: 04-07-16
Re: too many methods  
Jul 19, 2004 5:27 PM (reply 6 of 16)



 
As well, what about defining classes: Database, Relation, Record and Column?
 

Posts:37,103
Registered: 3/30/99
Re: too many methods  
Jul 19, 2004 5:48 PM (reply 7 of 16)



 
As well, what about defining classes: Database,
Relation, Record and Column?

Yep. And if you do that, then you may decide that rather than DBWriter/Reader classes, a DB would have its own write or print method, which might in turn just call the write/print method of each of its Records.

This is one of the trickier parts of OO--you want an object to be responsible for itself, to perform its own behaviors, rather than passing it as data to other objects' methods. But if you get too carried away with that, you end up with a god object that does too much and is too tightly tied to the environment in which it operates.

There are always tradeoffs, and rarely is there one right answer.
 

Posts:52
Registered: 7/6/04
Re: too many methods  
Jul 19, 2004 11:40 PM (reply 8 of 16)



 
the thing is, all these operations make use of some public methods, if i write sepearte classes, then i have to repeat these public methods that use private fields of class shell, i could nt figure out a clear way to do this.
 

Posts:52
Registered: 7/6/04
Re: too many methods  
Jul 20, 2004 12:06 AM (reply 9 of 16)



 
many thanks for the reply, i have redesigned my program and i think i l divided these operations into classes below:

Refactoring Shell
- 0, 1, 2
- RelReader (getRel())
1. File (byte, character)
2. Console
- RelWriter 17,19
1. File (byte)
2. Console
3. HTML
- DBIO 20,21
1. save database.
2. read database
- RelHandler 3,4,18
1. create relation
2. configure relation
3. delete relation
- BOPHandler (Basic operation handler) 5-7
1. add records
2. delete records
3. update records
- SOPHandler (Set operation handler) 8-11
1. union
2. intersection
3. difference
4. product
- ROPHandler (Relational operation handler) 12-16
1. rename
2. select
3. project
4. join
5. divide

are they reasonable? (i m a bit stuggled with the names as you can see)
 

Posts:2,909
Registered: 13.8.2003
Re: too many methods  
Jul 20, 2004 12:44 AM (reply 10 of 16)



 
Well, I would rename your acronym classes, you don't need to save space.
How about RelationalOperations, SetOperations, BasicOperations ?
 

Posts:6,750
Registered: 1/25/04
Re: too many methods  
Jul 20, 2004 8:38 AM (reply 11 of 16)



 
How about RelationalOperations, SetOperations,
BasicOperations ?

I wouldn't call them that unless an instance of RelationalOperations represents a group of relational operations. If it's something that handles relational operations, then I think RelationalOperationHandler is better.
 

Posts:52
Registered: 7/6/04
Re: too many methods  
Jul 20, 2004 5:39 PM (reply 12 of 16)



 
many thanks for the previous relpy, i took a look at Fowler's refactoring book today, but i thought that what i need to do is to handle operations using many helper classes, whereas refactoring is to break one operation itno different tasks (a series of transformations).

i just a bit confussed what i shd be looking at now, refactoring or design patterns? maybe what is the best for me is to build the system (dirty programming) andthen see what i can do, but that wont be what people do if they know what is the right thing to do at the beinging, right?
 

Posts:37,103
Registered: 3/30/99
Re: too many methods  
Jul 20, 2004 7:17 PM (reply 13 of 16)



 
Refactoring and design patterns are both useful, and yoou don't have to pick one or the other. If you're new to OO programming (which seems to be the case) then it's worth playing around with both.

Don't worry about getting things exactly right this time. Do the best you can, think about why you make the decisions you do, and post your decisions here for commentary.

It's a learning process, so you'll make a lot of mistakes, but the idea is to get as much experience as you can, and learn from your mistakes and from what others who've been there can tell you.

Good luck!
 

Posts:2,909
Registered: 13.8.2003
Re: too many methods  
Jul 20, 2004 10:50 PM (reply 14 of 16)



 
How about RelationalOperations, SetOperations,
BasicOperations ?

I wouldn't call them that unless an instance of
RelationalOperations represents a group of relational
operations. If it's something that handles relational
operations, then I think RelationalOperationHandler is
better.

Well actually I wouldn't call them that either...my brain wasn't functioning, RelationalOperationHandler was my first choice too.
 
This topic has 16 replies on 2 pages.    1 | 2 | Next »