Real-World Hierarchy

Another staple of object-oriented programming is that the real world is organized into objects, and objects are associated with other objects in a hierarchy. In reality, objects found in the real world form one of two kinds of hierarchies: a static hierarchy or a dynamic hierarchy.

Objects in a static hierarchy dont change or change very little over a long time period. Most things in nature are objects that have a static hierarchy. These are also the same objects used to describe the concepts of object-oriented programming.

An object in a dynamic hierarchy frequently changes its relationship with other objects in the hierarchy. Objects used in business applications typically have a dynamic hierarchy. In fact, some business objects tend to have a matrix hierarchy that consists of cross-relationships. Youve probably seen this in organizations for which youve worked where some workers (objects) report directly to one boss and have a cross-reporting relationship to one or more other bosses. Then the relationship changes when a reorganization occurs within the firm.

Relationships among nearly every object used to model an organization are fluid and therefore dont lend themselves to the nicely organized concepts defined in object-oriented programming.

A dynamic hierarchy of objects used to model an organization can become troublesome to programmers who must apply object-oriented theory in order to model the organization within an application. Programmers might find themselves trying to fit an octagonal peg into a round hole. The peg is almost round, but not round enough to meet the definition of the circle.

The Morphing of a Hierarchy

Whenever a programmer encounters a conflict between object-oriented programming theory and the real world, they have a tendency to carve the real world to adhere to object-oriented programming theory. What results is the morphing of the hierarchy of the real world when the real world is modeled in an application.

Morphing is evident when a real-world object is defined as a subobject. A subobject is a division of a real-world object. An object has an is a relationship with a super class. For example, a surfboard is a vehicle. A subobject might have an is almost relationship with a super class, such as a tabletop is a vehicle when it is used as a surfboard.

The issue for a programmer is how to handle all the variations that exist in the real world that are almost like well-defined objects. Polymorphism is a concept many programmers use to address this issue. Previously in this book you learned that polymorphism enables a programmer to use the same name for slightly different behaviors by changing the argument list to specify which variation of the behavior to use in the application.

At first glance, polymorphism seems to address this issue, but what constitutes slightly different behavior? Can a behavior that varies by 25 percent from the original behavior be considered a slight difference? If so, then polymorphism can be applied. If not, then a new member function needs to be defined.

The real world has many is almost objects that behave similarly to another behavior, but the degree of the similarity falls within a very wide range. The programmer must decide how similar a behavior is to another behavior and be careful not to morph the original behavior too much; otherwise , application programmers wont recognize the member function.

Lets say that an ordering system has multiple ways to retrieve an order. The order is an object that has member functions an application programmer can use to retrieve an order. If there are 30 ways to retrieve an order, then there could be 30 versions of the function that retrieves an order. Is it feasible for the application programmer to learn all 30 versions of the function? It might be more efficient to define more functions with fewer versions, where each function focuses on a set of ways to retrieve an order.

Is a Problems

As you learned in earlier chapters, a programmer determines whether an object should inherit another object if it passes the is a test. The is a test asks the question, Is object A an object B? If so, then object A can inherit object B. For example, is a graduate student a student? If so, then the graduate student object can inherit the student object. If not, then the graduate student object cannot inherit the student object.

The is a test isnt as flexible as a has a relationship, and some real-world objects dont have an is a relationship with other objects but do have a has a relationship with them. This is true in business applications where there is a dynamic hierarchy among objects.

Its also worth noting that although inheritance and containment define two classes that are very closely related somehowa truck is a vehicle, and a vehicle has a(n) enginesome objects arent so closely related , but still need to interact with other objects. We are referring to collaboration , which is described in more detail in the section titled Common Procedures.

Collaboration is a means to define how objects will work together, without having to define them in terms of inheritance or containment.