A design issue...

Thread view:

dushkin - 29 May 2007 16:40 GMT

Hello all,

I am writing a command line application which in general deals with
getting input from sockets and passing it to DB, archiving it etc.

The project is highly configurable according to customer needs. It
uses a configuration xml file to define for example DB table schems,
intervals, etc.

My project manager insists that I should use command pattern in order
to wrap each atomic operation. For example, LoadToDbCommand,
ArchiveCommand, GenerateFileCommand, Etc.

He explains this demand by giving the design more tolerance and
flexibility to cutomer "craziness"... For example, if one of the
customers will want to play a movie in the middle of process, it will
be easy to add this operation...

I can't really see the advantages. I know command is used typically
for undo operations. I can see another burdening layer of
architecture.

What do you guys think?

Thanks, dushkin!

Reply to this Message

Boris Stumm - 30 May 2007 10:45 GMT

> I am writing a command line application which in general deals with
> getting input from sockets and passing it to DB, archiving it etc.
[quoted text clipped - 15 lines]
> for undo operations. I can see another burdening layer of
> architecture.

I see no burdening layer here. After all, if you have many different
operations to do, you will end using some sort of "command pattern"
anyways, maybe a bit hidden and not like the well-known pattern. So,
why do you not want to make this pattern explicit, giving your code
a structure that is well-known to others and approved? And the command
pattern has not necessarily something to do with undo.

Reply to this Message

dushkin - 30 May 2007 14:36 GMT

Hello Boris,

I think that the command pattern is generally used to write aside
the list of commands being taken, so you can make some use of it later
on, For example in the case of UNDO.

I currently can not see any situation like this in the future, so I
can not see the need for implementing this pattern.

Moreover, if I will work this way, I will have to build up to X
commands lists to X customers....
If I will use command arguments, they will be accesible for every
customer. Isn't it an advantage?

Boris Stumm :

> > I am writing a command line application which in general deals with
> > getting input from sockets and passing it to DB, archiving it etc.
[quoted text clipped - 22 lines]
> a structure that is well-known to others and approved? And the command
> pattern has not necessarily something to do with undo.

Reply to this Message

Boris Stumm - 31 May 2007 13:00 GMT

> I think that the command pattern is generally used to write aside
> the list of commands being taken, so you can make some use of it later
[quoted text clipped - 7 lines]
> If I will use command arguments, they will be accesible for every
> customer. Isn't it an advantage?

I am not sure if I understand you right, but let me try ;)
Your current alternatives are:

1) Control the application by command line parameters (your preferred
solution)

2) Give the user a menu and a prompt where he has to enter the commands
he wishes to be executed.

This choice has nothing to do with the command pattern. The command
will be the same, and with the command pattern, you'll probably
encapsulate each command in its own class. If this command is executed
because the user pressing some button, or because of some command line
arguments, does not really matter.

And if you want to constrain the commands visible to a customer, you
just could put a .properties file where for each command it is specified
if it is enabled or not.

Reply to this Message

A design issue...

Free Magazines