This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi Bryan, what app are you making? How do you if class A depends on class B or any other class in fact.
All in all, this is not a design pattern but more OO problem. Sorting out what each class purpose and the methods in each class is what you need to do first. Then design patterns can help and make it better if used properly.
Bryan, I agree with Tsang that this is an OO problem. The number of methods in your class do not matter if all of the methods make sense for that object. Don't break it up into multiple classes unless it makes logical sense to do so.
Based off your vague description I would read up on the MVC pattern (aka Model-View-Controller). Since you have a front view (your gui), some type of business logic, and back end DB calls, I think this pattern would be the most helpful.
~Currently preparing for SCJP6
Joined: Dec 26, 2008
thanks again for the reply.
So, when do you decide to break them into multiple classes? what is the factor determines that? sorry for asking such a basic question...
because i always find myself asking should this method be with a separate class or just keep it in the same class.
The breaking up of classes into smaller classes is known as Refactoring, I would recommand you read Martin Fowlers Refactoring book.
In short, any class should only have one responsibility, anything that is not part of that responsability should be moved
to a second class.
Sometimes it is possible that class B is no longer paying for itself, in this case it could be quite useful to merge that functionality back into class A, this is all discussed in the Refactoring book.
Having class A use class B is know as delegation.
As an example of refactoring, suppose you have a class of Car, and inside Car you have methods and fields that describe the
engine that the Car has.
It could be considered that the engine methods and fields be moved to an Engine class. This allows Car to focus on being a Car and the Engine focus on being an Engine.
Inside Car you might provide pass-through methods that call off to the Engine to return values, or you might just provide a getEngine method, which would return the engine object belonging to a given instance of Car.
Hope this is helpful.
Joined: Dec 26, 2008
learnt something again! will definitely check out that book!