>>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.
>
>Example 1 and 2 are a design for implementing a flexiable and modifyable security management sub system. Example 1 use inhertiance, example 2 uses aggregation and delegation to accomplish the same goal. The goal is NOT inheritance, it is a flexible and modifyable implementation. Part of the problem with inheritance is that so many developers see it as a goal rather than a tool used to accomplish a goal.

Hmmm. this may be not a black or white thing. To me, indeed i see inheritance as a goal, because I like to see hierarchies in this way. When you look at the charts you've made for these examples, Example1 represents the solution as it is represented in the real world. Example2 does shows more of implementation details, the design seems to be lost in it. When designing systems I find example1 more clear and straightahead. In fact you may design the system by example1 and implement it by example2. maybe i'm too bound to OOD, maybe my sight is blurred with it.

>>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
>
>Yes I do have to change code in the one interface class, however I don't need to change code is any of the client objects (those that call on the interface class for services) because the interface of that class has not changed. The interface class is acting as a mediator between the clients and the behavior clases thus insolating them from changes in each other. Obviously, if either the behavior or client classes change their interfaces I have to adapt the security interface class for that, but I don't have to make changes to all of the behaviors when the client changes.

>>>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.
>
>Example 1 was similar. The issue is this, you ahve a class, securityInterface, that define the interface for all security manager classes. From it you create a NovelManager class with the specific code for Novell and an NTManager class with NT's behavior. All is well. Then you need to create a security manager class for a UNIX server, you decide that this class needs some extra properties and another method.

For what purpose ? If for extra functionality I can't see the problem ! You've got to do this for example2 as well. If these enhancement are UNIX specific, you've got to do it in the interface as well in the Unix_security class, where as with inheritance you've only to enhance the derived class.

If for implementation for the UNIX security model, these extra methods and/or properties are only required for internal use, so the external interface doesn't change.

>If you add the properties and method to the UNIXManager you have destroyed the common interface and every client will need to altered to make use of the UNIX class.

When I make enhancements, the extra methods or properties form not a problem to existing client as long as the existing properties and methods are still supported. IMO opinion this should be the cases if you want to support transparancy.

>If you put the new properties and methods in the SecurityInterface class, you also must visit every client and adapt it to the new interface.

>Example 2 doesn't have this problem. Changes to the behavior class wil require some work on the interface class but no the client classes and vice versa.

Again what kind of changes ?
I don't see this, IMO each derived class acts as interface, providing methods and properties. How should these new method affect the interface to the client in model1 and not in model2 ??

Maybe this a stupid question, but I simply don't see it: can you get more concrete ?

Walter,