>>No. All classes have a Behavior property. But that doesn't mean there's only one Behavior object for the whole app at runtime. The whole idea is that we can have A LOT of Behavior classes. And, of course, we can instantiate and use them as we want at runtime. It's extremly flexible and it can be done at runtime.
>>
>From this I conclude that your Behaviour is not pointed to by a
> property! You 'instantiate' kind of when you need it. In my scheme
>Behaviour functionality is added at base class level, so you know
>it's there, and the maintenance can be inherited...

Yes, it is a property at the base level. But you don't instantiate a Decorator and don't link it to the property if you don't need it. I mean you have a Decorator linked to an object only if you need to "decorate" the object. And, of course, you can decorate Decorators.

>>We can have Behaviors to modify only the Click method, only MouseMove method, etc. Or Behaviors to modify security rights/levels. Or anything else we can imagine. And we can play with them as we want at RUNTIME.
>
>I fail to see at this stage why I would want to 'modify' these
> methods, and at runtime, meaning that the response to an event
>would be different depending on a particular state of the program.
>Interesting, but not high on my list of priorities (the dyno in me
> probably! :)).

Steven Black has a very good example for popup menus on right click using this technique. The right click menu is context sensitive depending where the object is instantiated.

>... and he got that from Pattern theory I think.

Probably.

Vlad