Read an Excerpt
Chapter 8: Expanding Our Horizons
OverviewIn this chapter In previous chapters, I discussed three fundamental concepts of object-oriented design: objects, encapsulation, and abstract classes. How a designer views these concepts is important. The traditional ways are simply too limiting. In this chapter I step back and reflect on topics discussed earlier in the book. My intent is to describe a new way of seeing object-oriented design, which comes from the perspective that design patterns create.
In this chapter,
- I compare and contrast the traditional way of looking at objects—as a bundle of data and methods—with the new way—as things with responsibilities.
- I compare and contrast the traditional way of looking at encap-sulation— as hiding data—with the new way—as the ability to hide anything. Especially important is to see that encapsulation can be used to contain variation in behavior.
- I compare and contrast the traditional way of using inherit-ance— for specialization and reuse—with the new way—as a method of classifying objects.
- The new viewpoints allow for containing variation of behaviors in objects.
- I show how the conceptual, specification, and implementation perspectives relate to an abstract class and its derived classes.
Perhaps this new perspective is not all that original. I believe that this perspective is one that many developers of the design patterns held when they developed what ended up being called a pattern. Certainly, it is a perspective that is consistent with the writings of Christopher Alexander, Jim Coplien, and the Gang of Four.
While it may not be original, it has also not been expressed in quite the way I do in this chapter and in this book. I have had to distill this way of looking at patterns from the way design patterns behave and how they have been described by others.
When I call it a new perspective, what I mean is that it is most likely a new way for most developers to view object orientation. It was certainly new to me when I was learning design patterns for the first time.
Objects: the Traditional View and the New ViewThe traditional view: data with methods
The traditional view of objects is that they are data with methods. One of my teachers called them "smart data." It is just a step up from a database. This view comes from looking at objects from an implementation perspective.
The new view: things with responsibilities
While this definition is accurate, as explained in Chapter 1, "The Object-Oriented Paradigm," it is based on the implementation per-spective. A more useful definition is one based on the conceptual perspective—an object is an entity that has responsibilities. These responsibilities give the object its behavior. Sometimes, I also think of an object as an entity that has specific behavior.
This is a better definition because it helps to focus on what the objects are supposed to do, not simply on how to implement them. This enables me to build the software in two steps:
1. Make a preliminary design without worrying about all of the details involved.
2. Implement the design achieved.
Ultimately, this perspective allows for better object selection and definition (in a sense, the main point of design anyway). Object definition is more flexible; by focusing on what an object does, inheritance allows us to use different, specific behaviors when needed. A focus on implementation may achieve this, but flexibility typically comes at a higher price.
It is easier to think in terms of responsibilities because that helps to define the object's public interface. If an object has a responsibility, there must be some way to ask it to perform its responsibility. How-ever, it does not imply anything about what is inside the object. The information for which the object is responsible may not even be inside the object itself.
For example, suppose I have a Shape object and its responsibilities are
- To know where it is located
- To be able to draw itself on a display
- To be able to remove itself from a display
- getLocation( ... )
- drawShape( ... )
- unDrawShape( ... )
Interestingly, you will find that focusing on motivation rather than on implementation is a recurring theme in design patterns. Look at objects this way. Make it your basic viewpoint for objects. If you do, you will have superior designs.
Encapsulation: the Traditional View and the New ViewMy object-oriented umbrella
In my classes on pattern-oriented design, I often ask my students, "Who has heard encapsulation defined as ‘data hiding'?" Almost everyone raises his or her hand.
Then I proceed to tell a story about my umbrella. Keep in mind that I live in Seattle, which has a reputation for being wetter than it is, but is still a pretty wet place in the fall, winter, and spring. Here, umbrellas and hooded coats are personal friends!
Let me tell you about my great umbrella. It is large enough to get into! In fact, three or four other people can get in it with me. While we are in it, staying out of the rain, I can move it from one place to another. It has a stereo system to keep me entertained while I stay dry. Amazingly enough, it can also condition the air to make it warmer or colder. It is one cool umbrella.
My umbrella is convenient. It sits there waiting for me. It has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. Sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me!)
In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors.
Most people call them cars.
But I think of mine as an umbrella because an umbrella is some-thing you use to keep out of the rain. Many times, while I am wait-ing outside for someone to meet me, I sit in my "umbrella" to stay dry!
Definitions can be limitations
Of course, a car isn't really an umbrella. Yes, you can use it to say out of the rain, but that is too limited a view of a car. In the same way, encapsulation isn't just for hiding data. That is too limited a view of encapsulation. To think of it that way constrains my mind when I design.
How to think about encapsulation
Encapsulation should be thought of as "any kind of hiding." In other words, it can hide data. But it can also hide implementations, derived classes, or any number of things. Consider the diagram shown in Fig-ure 8-1. You might recollect this diagram from Chapter 7, "The Adapter Pattern...."