>That may be the main difference between the two different aproaches, and this is the main difference between VFP's inheritance and the VB interface appraoch.
>Your' trying to simulate inheritance, but you've got to mannually take care of some things to accomplish the same inheritance VFP does natively.


Walter,

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.

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.

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.

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