>>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.
>
>The two diagrams are not inheritance diagrams but object diagrams. They represent aggregation in example 1 and composition in example 2. Where the classes for each obejct derive from is not even described in those diagrams. That's why, in example 2, I said the behavior objects could actually be subclasses of the container they are in.

Hmmm. I'd really prefer example1. Because the implementation directly seems to follow the design. Making an inheritance diagram an implementing it in another way seems unusual to me at the very least. Only if there are restrictions to the inheritance model, we might justify another implementation. I seem to fail to see them in this case though.

Point i'm trying to make is to draw as muach parralles between analasys, design and implementation, therefor I do not think consider example 2 a logical implementation in this case.

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

>Not necessarily, if my interface provides a CallMethod method that receives the object reference doing the call and the method name requested, then the iexternal interface of the security manager is constant. ONly clients that want a new behavior need to call the CallMethod and request. Tyhe techical details of how the method call is forwarded and how the behavior is implemented is complete isolated from the client.

What are you doing ? Disagreeing with your own response ?

Let me try to explain my thoughts another way.

If the interface cannot change (for whatever reason) this means that:
- The interface (in terms of methods, events or properties) of the interface itself cannot change (Example 2).
- The interface of the derived class cannot change (example 1).

The question that follows: What can't be done within the derived class itself but is possible by using interfaces ?

I can't figure this out. Please help in this.


>>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.
>
>No, in example 2, I don't have to alter the external interface at all. I do have to be attentive to future changes when I design that interface in the first place. I was once asked in the past why my n-tier business object example used GetField and SetField methods instead of a SCATTER NAME Object to move data around.

Seems another situation to me. Scatter memvar is the actual implementation. Changes to the implementation requires a rewrite for everytime it's used in code. By ecapusulated objects you can change the implementation without changing the interface. This both applies to example1 or example2.


Wait a minute..... Do you try to say that:

If in the interface there is some logic that finds out itself what kind of NOS is used and therefore the client has not to find out itself which object to instanciate (example 1) and therefore is more encapsulated ?

You might be right on this one. But then if this is a requirement, I might build just an interface arround example1, to abstract the whole thing.

Walter,