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%). ... > > 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 ended up having the command.execute() do a model.executeThisTypeOfRequest(request, args ...); and then passed the request (which just an enum type to notify for the hint.
... > > model.execute(this) requires the model to know about the commands, which > sounds like a bad dependency ... > > i don't like all the switches, any way to get rid of these switches?
Convert switches into polymorphic calls.
sure
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.
right. the one in the model went way because each commmand did a mode.executeThisTypeOfRequest(request, args ...);
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
lets see if i get this. you are suggesting that i should have in the scaleCommand.execute() a model.scale(this). and by stuffChanged and updtateStuff i assume you mean setChanged and notifyObservers in java? no, i see below that you want flavours of updateStuff (but the java observe interface just has one method. and the list of observes is private so subclassing observer and observable is not possible. i would have to roll my own. probably a needless complication since this is a simple app. but this is clearly a right thing to do when things get more complicated.
i passed the request in instead of this (the command) i.e. scaleCommand.execute did a model.scale(this.request, args). since i thought that while the model is depenent on the requests, the commands tend to be things like scale to 200%, 300%, etc. so i thought it would be better to keep the model independent of the commands. the only additional data in the command is stuff like the argument to scale by. what do you think?
. If you have fifty commands you might end up with 6-10 different kinds of updates.
i expect a slightly smaller ratio of commands to request types, but i get the idea.
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.
got it - nice insight. also, made me look in the pattern hatching book. there is a nice discussion of multiple observable/observers that leads to the visitor pattern. interesting.
right now, the switch in update either does nothing (the guy fell on help or about), sets a new image to be repainted and repaints the entire screen or just repaints since the command was just an scroll. so it is fairly simple, in that the switch cases fall through to only about 3 cases right now. but it is a replication of the switch in the request factory.
So, you need several variations on update() instead of having a switch inside update(). This is essentially what the Java Listener does.
i will look at the listener. maybe it would be appropriate to switch over to that.
thanks for your assistance.
p.s. any chance of a second edition of your gof book? it has been about 8 years now:)
--- ray tayek http://tayek.com/ actively seeking mentoring or telecommuting work vice chair orange county java users group http://www.ocjug.org/ hate spam? http://samspade.org/ssw/
_______________________________________________ siemens-patterns mailing list [EMAIL PROTECTED] http://mail.cs.uiuc.edu/mailman/listinfo/siemens-patterns
