>> Yes, you can do it, but it's an useless overwork.
>>
>All it takes is Parent.Behaviour= .null. in the Parent.Destroy() method,
>and repeat this in each baseclass that you want to own a Behaviour
>object.

Are you sure that Parent will be always before Behavior in the destroy sequence?

>> It means that each time the container will scan its collection of objects
>> (Refresh, etc), it will process some extra objects. And I don't see any use
>> of it. It will only slow down some actions.
>
>Yes but if you _want_ the functionality of Behaviour, you cannot add
>without _some_ code, can you?

I still don't see what advantage would it be to link Behavior objects to the container.

>> The real power of these Behavior classes/objects is that you can chain/hook
>> them.
>
>So what is it that you _do_ advocate?

All classes can have a Behavior properties. Behavior classes will have it also.

Lets say we want to modify the Click method using the Behavior. It will look like this:

if type( "This.Behavior.Name") = "C"
   *-- Yes, there is a Behavior set for this object. Use it.
   This.Behavior.Click()
endif
*--Here goes the usual code for this Click method.

So, now we have a "hook" to te Click method. We can modify the Click method at runtime by using/changing the Behaviors. But don't forget that Behavior class has the same hook in its Click method. So, we can do the same thing for the Behavior object and for Behavior's Behavior object, and so on.

What's very good, it's that all these can be done at runtime. It's like you would modify the hierarchy of your classes at runtime!

Please note that in the previous sample Click is prehooked. It can be also posthooked if the hook is in the end of the method. But NEVER do both for the same method.

Vlad