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.
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?
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.
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 (firstname.lastname@example.org) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Joined: Jun 13, 2004
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’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com