>>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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only