So if I understood making a generalization private would be the equivalent of a regular generalization, and then overwriting all operation, making them private and calling the parent operation?
That is how it looks from outside, yes. But there are subtle differences.
Besides, are you sure this is a good idea?
What happens when I have a variable of type "Superclass" and it happens to be filled with an object of type "Subclass"? Am I now not allowed to call any of the operations on my variable anymore since they've been made private by the "Subclass"?
In my special cases I want to achieve exactly this. It's about how to design interfaces, that are solely internally visible. In fact a (public) client will not be able to have a variable of type superclass filled in. An internal client may receive a 'variable' (or better an interface ref) from the subclasses though.
We had a recent discussion about the deprecated <<friend>> dependency stereotype here. That's the way how I factored out such <<friend>> dependencies from internal clients.
When you design frameworks this is a pretty useful pattern, to make your APIs 'idiot proof'
. You can prevent your clients from using interfaces, they shouldn't use (directly), already at compile time.
WBR
Günther
[edit]PS.:
1. Actually I'm using an <<invariant>> constraint with the value 'protected' on the generalization, instead of a note.
2. I've investigated further, and see that it seems to be a more C++ related concept. At least C# and Java don't support it that way, these have a concept for module internally visible classes though AFAIK.
[/edit]
