my dog learned polymorphism
The moose likes Beginning Java and the fly likes design pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "design pattern " Watch "design pattern " New topic

design pattern

bryan lim
Ranch Hand

Joined: Dec 26, 2008
Posts: 140
hi all,

i have a java application where there is only a single class and many methods.

i decided to create around two classes to separate the methods (i am not sure if there is any incentive to do this)......

therefore creating:

from A class -----> A class + B class + C class + D class

but due to the dependency, i gonna have B extends C and C extends D.......

will there be a problem with this ? I am new to design pattern. need some suggestion here.

K. Tsang

Joined: Sep 13, 2007
Posts: 3130

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.

K. Tsang JavaRanch SCJP5 SCJD OCPJP7 OCPWCD5 OCPBCD5 OCPWSD5 OCMJEA5 part 1 part 2/3
bryan lim
Ranch Hand

Joined: Dec 26, 2008
Posts: 140
thanks K. Tsang for your reply.

it's a gwt application which get data off a database and display using google visualization and other charting tool.

because i will create an object of class B in class A.......... and class B will extends C and C will extends D......

Brian Legg
Ranch Hand

Joined: Nov 07, 2008
Posts: 488
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.

Good luck

~Currently preparing for SCJP6
bryan lim
Ranch Hand

Joined: Dec 26, 2008
Posts: 140
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.
Gavin Tranter
Ranch Hand

Joined: Jan 01, 2007
Posts: 333
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.
bryan lim
Ranch Hand

Joined: Dec 26, 2008
Posts: 140
learnt something again! will definitely check out that book!

thanks alot Gavin!
I agree. Here's the link:
subject: design pattern
It's not a secret anymore!