This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Employee is-a Person

Posted by Dave Andrews on 28 Oct 1998, 1:57 PM

I wonder if we're not getting a little far afield with some of our OO conceptualizations when we are debating the Employee/Person issue.
Both Rumbaugh (OO Modeling & Design, 1991) and Booch (OO A&D, 1994), and I'm sure others are very clear about inheritance being a Generalization/Specialization relationship. Booch is so bold as to assert that "Programming without inheritance is not OO". If an employee is not a person, what is it? A person is certainly not a specialization of employee. Rumbaugh addresses Employee/Person specifically, although not quite in the same context as in Bill's article.
Design Patterns (Gamma et al. 1994) gives us the State pattern to resolve such issues as Employee/Supervisor, both of which are still valid specializations of Person, assuming that they have some common behavior in the problem domain. In the Intent statement of the pattern, I quote "the object will appear to change its class".

While in practice, I do not take issue with the idea of composition making some types of change easier to handle, composition specifically denotes, according to the gurus, a 'part-of' relationship. In Bill's original article, Example2, has Apple composed of Fruit. Is Fruit part-of Apple? Or are we really using Apple as a wrapper for Fruit? Facade is a recognized pattern, but seems a little out of bounds if we are talking Composition vs. Inheritance.

It is interesting that Java conventions have us coding all classes as descendants of java.lang.Object, although to me this appears to be for primarily mechanical reasons, rather than meaningful 'is-a' relationship. Since Java allows only single inheritance (still a blessing IMHO), we're a little constrained from the start.