Title: Message
Greg,
Yes, you've hit the nail on the head.  My suggestion is basically a "Command" pattern.
 
> How is that better then the big case statement in the ControllerServlet and RemoteCallManager.callRemoteXXX()? 
 
Maybe it isn't better under your specific circumstances, but you asked for other suggestions to "plac[e] the callRemoteGetXXX(request) and showUserXXX(result, request, response) methods in separate files", and this would do that by putting those calls in dedicated classes extending or implementing Command.  Also, it would drastically reduce the size (and complexity depending on your perspective) of the servlet which will be bloated with the case statement approach.  I interpreted that as TOO bloated, but maybe I misinterpreted. 
 
But like you said it is just shuffling the work somewhere else, and it is a pretty subjective judgment to decide which is better.
 
Good luck,
 
Eli
-----Original Message-----
From: Greg Nudelman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 5:35 PM
To: jdjlist
Subject: [jdjlist] Servlets Design Question: Command Design Pattern?

Are you guys talking about a "Command" design pattern? i.e. you make a specific instance of the "CommandXXX" class (from a Factory, passing in a parameter) and then you call commandXXX.execute(). CommandXXX class ether extends (or implements) Command that has an abstract execute() that all the XXX subclasses need to implement.

Is that it?

How is that better then the big case statement in the ControllerServlet and RemoteCallManager.callRemoteXXX()?  I don't really have any re-try strategy implemented in my callRemoteXXX(), they are all pretty simple, set and fire kind of affairs... [READ: LEGACY STUFF] :-)

If you use the command design pattern, you would still have the big case statement (or hashmap retrieval), but it would be instead in the CommandFactory class...

I guess that might be a little cleaner, but it just seems less understandable, at least in the Servlet context.

I'll take a look, though...  Thanks guys!

Greg

---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk
---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk

Reply via email to