>>>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.

This is where we differ. I would use the decorator as a common
denominator for the framework. But you can of course have another
approach.

>

>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.
>
Indeed!

Regards,

Marc