Jim,

>I am in no way simulating inheritance, I am using delegation and a strategy pattern instead of inheritance. The only difference between design 1 and desing 2 is that design 2 has the behavior objects inside the secruity manager rather than outside of it.

Example 1 is using inheritance. Example 2 does the same thing, but is implemented in anotherway. How can you say that example 2 isn't simulating inheritance. I don't get it.

>If, in your approach, you encountered the need to provide a different interface for the specific behavior you would need to either violate the interface implemented in teh base of the calss tree or add to the interface of the exposed surface. In my design 2 I don't have to do either. I can createa new behavior class that has its own interface, and modify the code in the security manager to recognize the new interface of the new behavior object. The interface to everything else is still the same as the security manager's interface does not change.

Thats true. hmmm. The difference that pops up in mind, is that if enhancements where made in the baseclass (extra parameters, properties or methods) they're automaticly exposed to to the inherited objects. In your case you've got to change code in the interface

>>There are a lot of things that can be done using inheritance, but the only one that makes any sense to me is defining an interface. Every class library that I have seen that has mucho subclassing is also riddled with overridden emthods and introduction of extensions to the interface. In your example of security management if you create an NTManager and then subclass that for a NovelManager the question is, "Is the NovelManager an NTManager?". If you answer no then why is a subclass of an NTManager. Superclass-subclass is described as an is-a relationship, meaning the subclass is-a superclass, trnaslated this would say "The NovelManager is-a NTManager" and surely it is not.

As already admitted, this solution comes up when you're faced with a new variation to something already existing. Because time is limited I'm willing to implement it this way, though it's not the right thing to do. But when you've done the required research to solve this designflaw, you can change the hierarchy without any significant problems.

>An alteration might be to create a SecurityManager class to which both NTManager and NovelManager are subclasses. However even in this situation you would be risking changing the external interface to the clients of those classes when you introduce an new one.

Can you give an example of this. I don't seem to understand what you're saying here.

>My design 2 has the benefit of never changine the external interface of security maangement because the outside world talks to the security manager object and it in turn talks to the specific security behavior object inside it.


>One thing I really agree wholeheartedly with John about is that inheritance is extremely overused.

It might be, though I've got a strong feeling that it's overused by people who don't fully understand the OO model. To me, it's a great feature. It only has to implemented in the right way (I know, I do violate this one sometimes either).

OO has a massive number of methods for accomplishing a task and inheritance is only one of them. When it comes to supplying multiple behaviors, inheritance falls down pretty quickly in terms of maintenance and evolution. The strategy, bridge, and other patterns do a much better job of insulating one side from the other.

I never used this appraoch much, so I can't judge on the details of maintainbility and implications. I'm not able yet to put my finger on the sore wound. The point is that this appraoch very much seems like inheritance from the outside. The only difference (from the outside) I can come up with is that you always instatiate the same class, rather than the subclasses one.

Would you agree when I say that this aproach would be next best when your development tool misses inheritance (like VB) ?

walter,