Re: Design Patterns - Maze Examples

>
>> For Decorator, think of a file you have to send to possibly many places
>> via many methods. The basis method is to move file from place A to file
>> path B. You may also need to email it to someone: make an EmailDecorator.
>> If you need to FTP it anywhere, add an FtpDecorator.
>> And so on.
>
>This example is closer to a strategy than to a decorator. Don't forget
>something. The decorator is a strutural pattern, not a behavioral
>pattern as your example describes.
>
>In other words, the decorator allows you to add responsabilities to an
>object dynamically. There is a base class that your object will know
>that will be called the 'decorator' itself. That will let you inherit
>this base class to create child classes having different
>responsabilities. The main difference with the strategy, is that you
>can attach more than one decorator to an object. That means, you are
>using multiple decorators at the same time. In other words, your
>dispatching the responsabilites of something through several objects.
>The is the job of the object that is using the base class to iterator
>through all of them and notify them.
>

Very true. In the example I gave I was thinking of decorating - just as
you say - a base 'FileTransporter' which has some default behaviour (or
may be abstract) with other FileTransporters. Thus the one file would be
transported in many possible ways by many possible methods from the one
call by the client to .Transport(). Structurally, it's definitely not Strategy.
Each of the decorators could be thought of as a separate strategy (though
I think with a small s rather than a large one), but the way they combine
and add to each other definitely follows Decorator. However, Decorator
and Strategy have some overlap in the circumstances in which they can be
used so discussions like this are perhaps inevitable. I didn't go into
any details of how the FileTransporters would be implemented - I assumed
relatively trivial since the OP obviously knows about the pattern.
From another point of view - so what? Patterns aren't straight-jackets.
Start with a pattern that does more-or-less-what you want, change it until
it does exactly what you want. You start with pattern X, and incorporate
bits of pattern Y and maybe Z etc. Whatever you end up calling it is not
necessarily the most important thing: knowledge of patterns has lead you
to the solution and so patterns have proved themselves valuable. Accurate
naming *is* important for communication purposes, yes. In the example I
gave I would definitely use Decorator rather than Strategy in the name.


Cheers -


Simon

I really don't see how you are attaching responsabilites to your object
in this example. However, what you just said is true... the knowledge
of those design patterns is the key that is helping you to create an
efficient solution. There are several design patterns that are really
close to each others and this is why it's always good pratice to not
only use one at the time in order to achieve a specific goal.

At this point, I don't even know what the original poster thinks about
this... does he understand what is the decorator pattern now?

iscy