Two Human-Derived Metaphors


Two metaphors, inheritance and responsibility, arise from our observation of human beings. Both are important, and both are subject to some degree of confusion because the terms are used somewhat differently in different contexts.

Inheritance

Humans naturally aggregate similar things into sets (or classes). Another natural kind of thinking is to create taxonomies ” hierarchical relationships among the  sets. The most common example of this kind of thinking is Carolus Linnaeus s taxonomy of flora and fauna and the subsets of that taxonomy that are general common knowledge. Fido is a dog (example of aggregation and the subsequent identification of a set). The set Dog is a subset of Canine , which is a subset of Mammal , which is a subset of Animal . (The example taxonomy isn t complete, nor is it intended to be accurate ”merely illustrative .) We could also say that a dog is a kind of canine, which is a kind of mammal, which is a kind of animal. Taxonomies are tree structures.

Another kind of tree structure ”one that actually employs the term ”is a genealogical chart, a family tree . Because both the taxonomy and the genealogy chart use the same structure, a hierarchical tree, they have become a kind of conflated metaphor.

The terms parent and child , for example, are clearly appropriate for genealogy but are somewhat suspect when applied in the context of a Linnaean hierarchy. Nevertheless, it is common to speak of the superset/subset relationship in terms of parents and children. A superclass is Parent , and a subclass is Child . From here, it s but a short step to talk about children inheriting from parents.

At this point, the metaphor can be helpful or potentially misleading depending on how it is used.

According to the presuppositions of the object paradigm, a child class is a behavioral extension of the parent. A dog has all the behavior of a mammal plus some additional behavior that s specific to dogs. If we say that a dog inherits the behaviors of a mammal and mean by that statement that a dog can be asked to do anything that a mammal can do, we are using the metaphor properly.

Too often, however, the metaphor is used to assert that the child class inherits the internals of the parent class, an allusion to the fact that biological organisms inherit the DNA structures of their parents. This is a poor and potentially misleading use of the metaphor.

Behavior is the abstraction that we use to differentiate among objects, and it should be the only criterion that we use to establish our taxonomy. Using any other criteria will make our taxonomy more complicated at a minimum and erroneous at worst. In the real world, errors such as racism and sexism can be seen as characteristic-based rather than behavior-based taxonomies ”with the obvious negative consequences.

In the context of software objects, creating taxonomies based on internal structure (attributes or operations, for example) causes problems in numerous ways. One example is the need to create new classes of objects such as Customer and CreditCustomer just because one has different characteristics in some contexts than in others (a  credit rating, perhaps). It can also lead to an apparent need for multiple lines of inheritance when an object has characteristics that are part of the structure of two or more potential parent objects.

The desire for a child class to inherit internals of its parent classes can be better accommodated if we change the notion of inheritance from DNA to assets. It has been noted that an object has access to whatever resources it needs to fulfill its behavioral expectations. If we say that child classes have access to the resources of their parents via inheritance, that is, by virtue of the parent-child relationship, our use of inheritance remains consistent with the object paradigm.

Responsibility

We know an object by what it does, by what services it can provide. That is to say, we know objects by their behaviors. We are not interested, of course, in just any old behavior. We have specific expectations of our objects and are surprised if they deviate from those expectations. Because we expect objects to exhibit certain specific behaviors, we tend to hold them accountable for those behaviors. (We experience negative reactions such as disappointment and even anger if the objects let us down. ) We expect them to perform as advertised. Our thinking about the abilities of objects shifts from simple awareness of behavioral possibilities to expectations of service, of responsibilities. The capability is unchanged, but our perception of that capability is different enough to merit the use of responsibility as a label.

If an object states that it is capable of providing a given service, it should perform that service in all circumstances, and the results should be consistent. If an integer object says, I can add myself to any integer you provide and return to you the resulting integer, it would be very irresponsible if sometimes it returned a floating-point number or, worse , if it were an integer that was other than the one representing the summing process.

Responsibility implies that an object must assume control of itself. It must be capable of assuming responsibility for its own maintenance, for notifying others of any interesting and shareable state changes that it might experience and that other objects might need to be aware of, for making sure it s persistent when it needs to be, for protecting its own integrity, and for responding appropriately to requests for service from multiple clients . Just as it s improper for one object to assume a role as controller or manipulator of another, it s improper for an object to fail to assume responsibilities that make the need for external control unnecessary.

The notion of self-responsibility will play an important role in how we decide to allocate behaviors across a collection of objects.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net