1.7 Collaboration among objects

We’ve addressed two important ingredients that are part of object-oriented programming: class and responsibility. We classify objects based on their internal state and their behavior. We also strive to define a clear, focused responsibility for each class.

The remaining ingredient is collaboration. Once we decompose a problem into separate classes, the final application’s behavior will emerge from collaboration among objects of those classes. The final application — like a good sauce — is a blend of ingredients that complement each other.

There are a variety of ways to think about collaboration among classes. We’ll defer the details of different kinds of collaboration until  Chapter 3. Here, we’ll introduce two useful concepts:

• Composition

• Inheritance

When we think about following the Interface Segregation Principle, we often decompose something complicated into a group of simpler things. In many cases, we can design a model of the original (complicated) thing as a composition of the simpler things. We’ve already seen how composition works when talking about cars. A fossil-fueled car is composed of an engine, transmission, starter, headlights, and windshield, among numerous other parts. Each of these can be further decomposed into the active, stateful component. The headlight subsystem, for example, is off, on, or bright. A control changes the state of this system. There may be an automated sensor to turn lights on at night, and dim the bright lights when there’s oncoming traffic.

Decomposition exposes a potential problem. What if we have several things with common aspects? We have headlights, interior lights, and an entertainment system, all of which use fuses. Do we want to repeat the depends on a fuse aspect all over the class hierarchy? That sounds like a lot of copy-and-pasting, and potential nightmares when there are implementation changes.

To avoid repetition, we can use inheritance. It’s helpful to think of inheritance as an “is a” relationship. We can extract a feature, such as protected by a fuse. Each of the electrical components within an automobile is a component protected by a fuse: the headlight system is a component protected by a fuse; the entertainment system is a component protected by a fuse.

We’ll do this be defining a base class: Fused. Then, we’ll define subclasses that extend this base class. Many folks use the term superclass instead of base class. The UML diagram often shows the base class at the top of the figure. The class is, however, foundational, and the other classes build on it.

The Liskov Substitution Principle (and the Open/Closed Principle) provides guidelines for inheritance. We need to be sure that each subclass has the same interface as the base class: the idea is that any subclass can replace the superclass.

When thinking about headlights and the entertainment system both having fuses, this can seem a little odd. We don’t turn on the stereo when driving at night. (Well, maybe we do, but it doesn’t help us see the pavement.)

The subclasses don’t all do the same thing. They merely have a consistent interface. The headlights and the entertainment system both have an interface (a pair of wires) to the fuse and to the electrical ground. This interface fits the Liskov Substitution Principle.

When we add running lights to the headlight system, we are consistent with Liskov Substitution because the running lights use the same fuse. The use of long, flexible wires leaves the car’s systems open to extension. The use of a tightly sealed headlamp fixture makes the lights closed to modification: if we want to make a change, we have to replace the whole fixture; we can’t just push in a new bulb.

Now that we’ve started looking at object-oriented design, we’ll take a quick look at some legacy software that didn’t follow object-oriented design principles. We can start thinking about ways to refactor it from a mess of statements to some easier-to-understand class definitions.