On 5/29/03 2:40 PM, "Ray Tayek" <[EMAIL PROTECTED]> wrote:

> and when the user types a command or clicks on a wigit, i need to construct
> a command object for that request. ok, i have a command factory, with some
> additional logic for the case where i need to supply some parameters (i.e.
> scale to 150%). so it's a little messy but ok (maybe this is an interpreter
> or a small language)
> 
> now the view needs a hint for the update , so he wants the original request
> or command or something, so it looks like i should maybe pass the command
> along to *each* method call on the model (i.e. model.d4(D4 d4, Command
> command) and model.scale(1.5, Command command)). or have an execute in the
> model  (the commands execute method just calls model.execute(this), which
> require an ugly switch in the model (which does not seem to be where this
> belongs).
> 
> so i am thinking of passing the command to each model method that does
> something, so that update() in the  view gets an exact hint of what
> changed. (and of course there is another ugly switch or a bunch of
> instanceof's).
> 
> so command.execute() does a model.execute(this) which has a switch (or
> mode.method(parms, this) and update() gets a command (or request) and has a
> switch.
> 
> model.execute(this) requires the model to know about the commands, which
> sounds like a bad dependency. seems like command should be dependent on the
> model and not the other way around.
> 
> i don't like all the switches, any way to get rid of these switches?

Convert switches into polymorphic calls.  Now, you can't always do this.
The original switch (to build the command by parsing the input) is
necessary, but you don't need switches inside the model or the views.

command.execute() should not do a model.execute(this), it should do a
model.doStuff(this), and doStuff(aCommand) should call stuffChanged() on
itself, which will call updateStuff() on all its observers.  If you have
fifty commands you might end up with 6-10 different kinds of updates.
Although it is possible that a view has to respond differently to every
command, it is unlikely.  If that happens, the "command" is really a visitor
that is visiting the views.

So, you need several variations on update() instead of having a switch
inside update().  This is essentially what the Java Listener does.

-Ralph Johnson

_______________________________________________
siemens-patterns mailing list
[EMAIL PROTECTED]
http://mail.cs.uiuc.edu/mailman/listinfo/siemens-patterns

Reply via email to