aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Command Pattern, Max vs GoF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Command Pattern, Max vs GoF" Watch "Command Pattern, Max vs GoF" New topic
Author

Command Pattern, Max vs GoF

peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
I decided to use the Command Pattern as described by the GoF in Design Patterns. This uses Polymorphism with a subclass per command, it is quite different from the version of the command Pattern that Max suggests using an integer to encode the command and then a switch statement to decode it.

The polymorphic version results in a lot of small classes and a rather opague looking system that might leave a "junior programmer" lost, unable to see the forest for the trees. The procedural version is more straight forward, but uses some large switch statements on both the command and response ends of the communication.

Does anyone, especially Max have an opinion on this? Does the polymorphic version violate the requirement for simplicity?
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
I thought the whole point of the pattern was to remove the need for conditional logic. As soon as you start using more than a few bits of conditional logic, alarm bells should ring... this isn't a good approach.


SCJP 1.4, SCJD
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
I think it should be kept as simple as possible to pass the exam. Smaller classes are easier to debug, but once you have debugged them, functionality can be pasted into a larger class. Just as few classes as possible should exist, IMHO. IMHO, design is usable for maintainability purposes, and since this system is only required to be maintainable at the client level (it says so in the assignment) I would only "design" the client. Let the rest be as coarse as possible.

I put the cache and the io in Data class, both, although a proper design would be to provide an IO class and a Cache class, and even a better design would be to hide those classes behind an IO and Cacheable interfaces, and have the classes themselves created by a factory. That's uncoupling at its best. It could provide a way to a database in the future very easily. But how much time is it going to take? I just don't have that kind of time. So I have just two classes of import in suncertify.db: Data and Schema.

There's definitely a better way, but this way is enough to pass, IMHO.
[ August 25, 2004: Message edited by: Anton Golovin ]

Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by mike acre:
I thought the whole point of the pattern was to remove the need for conditional logic. As soon as you start using more than a few bits of conditional logic, alarm bells should ring... this isn't a good approach.


No, the point of the pattern is, to quote GoF "issue requests to objects without knowing anything about the operation being requested or the receiver of the request ... by turning the request itself into an object"

So both versions do that. I agree that the point of the polymorphic version is to remove the need for the conditional logic and to isolate the code needed to implement the operation. That's the version I'm using at present, but it leads to a proliferation of tiny classes. It wasn't bad when I was in the thin client camp with only 2 remote commands, but in the rich client version I've got 9 commands, so 10 tiny classes.

I know you will consider it treason to switch to rich, but my reading of the project requirements drives me in that ugly direction.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Command Pattern, Max vs GoF