>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.
>>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.
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.
>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. My answer, with SetField and GetField there is not dependenc of the interface to the data structure. UI objects just call SetField or GetField as they need to and changes to the underlying table has no effect on the interface to the business object. Now granted, a new field should not effect an existing UI control, but that is not my point here. My point is that in the long run, programming to interface is much more enhanceable then programming to implementation. So I spend a lot of time making sure my interfaces are flexible.
