Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2005

Tip: Looking for answers? Try searching our database.

class design question

Thread view: 
vk02720 - 14 Jul 2005 14:17 GMT
Hi,
I have different type of messages to be handled in my app. I wrote a
base class like
BaseHandler {
public boolean perform() {
}
}
I get a message with a String messageType.
Just to avoid making changes to the same file ( and intending to keep a
good design ), I subclass each specific message handler from
BaseHandler and override perform() for each message.
The issue is how to organize the classes properly.
For example, I have following function to return correct handler :
public BaseHandler getHandler(messageType) {
//return the correct Handler based on messageType
}
Which class should such function belong ?
Is this a normal way to solve such problem. It appears quite common!
Not sure if this conforms to any Design Pattern....
The code is in Java.

Please advise.

TIA
Chris Smith - 14 Jul 2005 14:46 GMT
> For example, I have following function to return correct handler :
> public BaseHandler getHandler(messageType) {
[quoted text clipped - 3 lines]
> Is this a normal way to solve such problem. It appears quite common!
> Not sure if this conforms to any Design Pattern....

It depends on the extent to which you want to isolate specific
BaseHandler implementations from the application.  You have a range of
options for trading off isolation of concerns against the intrinsic
complexity of the technique.  They include:

A. Write the method in BaseHandler, and make BaseHandler aware of its
subclasses.  This is simple, and accomplishes the goal that 95% of the
time you don't get people stepping on each other's toes.

B. Write a MessageDispatcher that knows about all the subclasses.  This
eliminates a circular dependency, and makes the abstract BaseHandler
more reusable, should you happen to care about that.

C. Write a MessageDispatcher and have it read a handler mapping file via
Class.getResource (could be as simple as a Properties file) and dispatch
as appropriate.  This removes registration of handler instances from
code.

D. Write a MessageDispatcher and have it read a set of handler mapping
files via ClassLoader.getResources and dispatch from there.  This
prevents anyone from ever having to edit the same file for different
handlers in the case where they are packaged and distributed separately,
such as being provided by different vendors.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Hemal  Pandya - 14 Jul 2005 18:13 GMT
[....]
> public BaseHandler getHandler(messageType) {
> //return the correct Handler based on messageType
> }
> Which class should such function belong ?

I have seen and implemented a lot of examples of this during my C++
days. A template implementation even allowed a set of classes to
register themselves as handlers of objects of a particular type.

The basic idea is as follows: All Handler classes are cloneable and
contain a static member of their own type. This static member is
instantiated with a special constructor which registers itself as the
handler for a particular message type. You still have to ensure somehow
that all these classes do get loaded.

In java world, all this is perhaps much better handled by a specifying
handler classes for various message types in a property file.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.