Suppose a class is developed that has three layers of inheritence
(generalization)(e.g. drawn on paper would look like a pyramid with three
levels). No suppose the root class can, at the same time, inherit from two
different legs of the tree (e.g. drawing a line from the root to one side
and from root to other side).
To give a more concrete example, say the root is a person class. The person
is either a soldier or civilian, the soldier is in the army, navy, air
force, or marines. In this case, a person can be in both the army and
marines (e.g. in the active marines, but also in the army reserve).
Would a generalization tree be appropriate for modeling this behavior? In
this case we would have to create a second object for the same person, but
with the marine attributes. The question then becomes, what happens if one
of the person objects changes an attribute inherited from the person class
(e.g. a name change)? Wouldn't both objects need to be updated?
Is a better way of modeling this to create another class (or a number of
classes) with a multiplicity that shows the 1 to many?
Person ------- PersonRole
specialized into all of the Roles that this person can play
in your system
See "object models" by Peter Coad and other places (e.g. Fowler, Analysis
First of all, I'd make a distinction between a conceptual (analysis) model
and a design model. In the conceptual model you probably don't need the
root class inheriting from it's children at all. Model it using
as the mechanism to depict roles. There is a nice, tight little example in
Fowler's UML Distilled book, I think, that shows roles. I've drawn up a
diagram of what I'm proposing you draw for the conceptual model and put
it on the web at an address below, but before you go look at it, hold on...
Let's talk about the design model, which I think you are more interested
in at this point. The answer is that we cannot answer your question
yet, if you want to build a flexible design that is resilient to change.
You need to find your underlying problem domain behavioral abstractions
and use those to drive your design model. At the end of the day,
your design model will probably look quite different from the conceptual
model. It will be more complex, but more flexible to change than if you
had just coded up the classes from your analysis model.
In the web page I put up, I show the before (conceptual) and after (design)
models based upon the payroll system in Robert Martin's first edition
of Designing Object-Oriented Applications ...
The supporting URL for this post can be viewed at:
hope this helps
John Goodsen Saguaro Software, Inc. / Training & Consulting in:
jgoo...@saguarosoft.com - User Centered Systems Analysis
http://www.saguarosoft.com - Object Oriented Architecture and Design
602.283.0142 / 888.298.2566 - Rapid Incremental Delivery S/W Process
"Example isn't another way to teach, it is the only way to teach. "
- Albert Einstein
faulty, as others have pointed out. Yes, better to think of person
adopting one or more roles.
I just wish to add the general point that it is often a mistake
to find hierarchies in your domain and map them onto inheritance
structures. Hierarchies often turn into something else.
Use an inheritance structure specifically to take
advantage of polymorphism and its ability to localise the
effect of implementation variations and different choices.
Graham Perkins, De Montfort University, Milton Keynes
>Use an inheritance structure specifically to take
>advantage of polymorphism and its ability to localise the
>effect of implementation variations and different choices.
My very little experience tells me that this is very sound advice. I am
working on a project that has uses just this. I have a root AB class and then
derive new classes. The new classes all use the declared methods in the root
class but all of the unique classes (actually there is another layer of ABC in
the branch I am working on) have very different needs.
Question is the root ABC.
SHortAnswer is a derived ABC.
Then from Shortanswer I derive TextQuestion, IntQuestion and FloatQuestion.
The first part of the name indicating the type of answer that is acceptable.
Obviously each concrete class has the same general needs, but each class has
different expectations of what those needs exactly are e.g. the need to screen
unacceptable answer is universally acceptable but each class has a different
idea of what an acceptable answer is.
In a previous project I made a stab at an inheritance structure based on
syntactic similarities and was advised against this. It took me a bit to see
the widom in it (the ideas of the classes were similar but not similar
enough). It was a record class and then from that I was planning to derive a
team record (wins, losses, ties) and then another one dealing with a
prognosticators record (guess right, guesses wrong).
Friends don't let friends post drunk!
To e-mail me remove NOSPAM.