>>A different design that is equally as effective would be;
>>

>>             ---------------------------------------------
>>             |               Security_base               |
>>             |                                           |
>>             | [ Novell Behavior Object ]                |
>>             | [ NT Behavior Object ]                    |
>>             | [ Win2000 Behavior Object ]               |
>>             |                                           |
>>             ---------------------------------------------
>>

>This is one that is a bit harder to understand to me. Placing an object into an container wich is derived from the container itself ? hmmm, i've got to think about this one. If they're not inherited, you would probably end up writing simular code for common behaviour for each object, or you would choose only to write exceptions into the behaviour objects. To me this seems a bit more complex. what happens when I need an extra object. I'd probably have to change both the security_base as the extra behaviour object. seems not very OO to me.

Walter,

No you would not need to change the security_manager at all, data drive it for what classes to use for which requests and all you ned to do is provide a new class with the new behavior. Use a factory pattern so that the security_manager constructs its insides on the fly, that is it creates the internal objects when they are needed and passes requests on to them.