The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Command Pattern: Parameters Map vs. DTO

I recently developed a Job Framework in order to elegantly create new types of jobs by orchastrating a set of reusable / job-specific commands. The general structure follows POSA's Command Processor and GoF's Command patterns.

I've been reading "Refactoring to Patterns" and saw an interesting difference between approaches to the Command pattern.  Whereas my parameters are passed through a DTO, the author looks them up in a Map. More specifically:

JobCommand(Job job, JobData jobData)
public void execute() throws JobCommandException


public HandleResponse execute(Map parameters) throws Exception;

Each JobCommand has its own interface for the jobData, so it casts it and pulls out the necessary information. My JobCommandProcessor organizes and runs the command, and passes around the JobData which implements the interfaces. I can then keep the commands independant and simply create new jobs that are composed of them, while maintaining one data object that can be persisted to a table.

My question is, which method do you prefer? I don't like using a Map because I'd be exposing all of the job parameters unless I transfered the elements into a new Map. I'd be inclined to create a rule engine, because I'd need to validate that the key is storing the correct object, is read/read-write, etc. Using a map could lead one to be lazy and use a shared attribute table for all job data, because writing a mapper would be a tad more work (good, bad?). I'd also expect the code to get messier as you constantly look up and validate parameters within the command, rather than moving that logic into the DTO. And since each command has a well defined operation, you don't need a general knowledge store that would be used system-wide and have lots of global information (such as UI data).

At the same time, one could argue that the Map approach reduces the number of interfaces and (optionally) requires only one table. You'd simplify your framework by either assuming everyone is trustworthy, or pushing all validation work onto the user.

Monday, December 11, 2006
I much prefer the map. It is far more flexible. Any layer of software can add parameters for any other layer and it doesn't require a recompile. Optional parameters are also handled cleanly. You can also have maps of maps so structured data is handled nicely. It also maps to XML nicely too. You can go the next step and listeners for changes too. And it's all generic.
son of parnas
Monday, December 11, 2006
It's a tradeoff of flexibility vs clarity. With the Map you have ultimate flexibility, but if you take it too far, it can become a real mess trying to decipher just who's using which entry in the Map for what.  With the DTO, it's clear exactly what's being passed around and the compiler will enforce that for you, at the cost of having to recompile if you need to change.

I used to be a big fan of the generic approach but I'm starting to swing more to the specific. It depends which is more  valuable for the kinds of things you guess will come up in the future.
Mike S Send private email
Tuesday, December 12, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz