子类之间的组成

Question

Is it possible or reasonable to have composition relationship between child classes?

For examples:

Staff has two childs, Waiter and Manager (Inheritance).

Manager contains a list of Waiter (Composition).

Or is there a better way of representing their relationships?

Answer 1

It is possible to have composition between child classes and sometime 'reasonnable' but in your case I would just model the relation between Waiter and Manager as an Association as de picted below.

Answer 2

Yes, it is (syntactically) possible to have composition between ANY two classes. If it is reasonable or not, depends on every single case.

In your case it is definitelly not a good idea, because of the semantics behind the composition.

As the name says it, a composition means a Whole-Part kind of relationship , very strong one. The "Whole" has a fuul control over the "Part", creates its instances, typically has them kind kind of hidden from the outside world and finally destroys them. "Part" most often than not does not exist out of context of the "Whole" and has no function besides its participation in the "Whole".

Possible examples: House and Window, Invice and InvoiceItem, Body and Head, etc.

Note that even those examples could require different type of relationship in different contexts (for example, in a robot manufacturing software, Body and Head could be linked with some other relationship, as Head could exist independent of Body :)).

Back to your question, I would use a simple association between Manager and Waiter . The nature of this relationship is weaker, a Waiter can certainly live out of context of his Manager, Manager might have certain control over Waiter, but it probably does not control his lifecycle.

I suggest you too use relationship names that are as meaningful as possible.

Manager contains a list of Waiter

is not very accurate and even misleading (that's why you were tempted to use composition in the first place). Manager does not control Waiter, he might be "in charge of", or his boss or something. Anyway, I prefer to use association roles, over then relationship names, as more formal.

Something like this:

Another possible relationship between Manager and Waiter is an aggregation . Its semantics is somewhere in between plain association and composition and often depicts a Group-Member kind of relationship. In this case it might make sense but is definitelly a matter of personal taste.

2nd VERSION (see kiwiron's answer and comment(s).

The idea is to separate between the personal and employment aspects of a Person . Each Person have only one "current" Position, but it can be easily changed, even keeping the existing Positions and "reusing" them.

This resolves the problem explained in the mentioned answer.

Which solution is the best in your case can only be determined by yourself. :)

Answer 3

I think the basic class hiearchy is incorrect. A waiter can become a manager, and vice-versa. This suggests that both Waiter and Manager are roles played by Staff and these roles are time-constrained . Inheritance should not be used under these conditions.

I suspect that it is the manager role that has a list of waiters - not the manager staff member. (ie if the manager resigns, the waiters will still be in the list for the replacement manager)

Try googling "Peter Coad". His data modelling techniques have changed my way of looking at the data modelling world.