Object Oriented Design: Objects as Metaphors

Ted Felix

When I first learned object oriented programming in the late 80's and early 90's, I was confused. The concept of objects, encapsulation, inheritence, polymorphism, and genericity were all very clear to me. It made sense to use these powerful constructs to model the real world within software. But, something was missing. All the object oriented programming books I was reading at the time focused on modeling the real world. None of them mentioned that this wasn't enough.

It wasn't until I read Coplien's Advanced C++ Programming Styles and Idioms, and then the Gang of Four Design Patterns book that I started to see, though not necessarily recognize until the mid 2000's, a glimmer of what object oriented programming is really about. Then, reading Larman's Applying UML and Patterns finally made everything clear.

Let's use an example from Coplien's book: the Envelope/Letter Idiom. The most important thing to note about the Envelope/Letter Idiom is that it is not a model of a real world object. It sure sounds like one, but instead of being real, its name is metaphorical. This implies that it is ok to have objects that are not real world models.

Although it may not seem like a big deal, when you've had it drilled into your head that object oriented programming is all about modeling the real world, this can be a big step. That one can also create a metaphorical world to solve problems within a software system is a powerful idea. I would even argue that object oriented software systems can't exist without at least one metaphorical object.

The Controller

Probably the most common metaphorical object found in object oriented systems is the controller object. It crops up in many forms, but in its simplest form, it is an object that creates all the other objects in a system and gets them going. Parnas in his 1972 paper entitled On the Criteria To Be Used in Decomposing Systems into Modules that is usually cited as an important point in object oriented thinking (note that Simula predates this paper, although the book Simula BEGIN does not) includes a "Master Control" module in his design. This is clearly a metaphorical object tying together the other objects in the system. Without a controller object of some sort, object oriented systems can do nothing.

This is what initially perplexed me. Who tells all these wonderful real world models what to do? Which class/object is responsible for this? The answer is that modeling the real world isn't enough. One must also devise a model comprised of metaphorical objects to create a successful object oriented system.

Object Oriented Programming Books

As an example of a book that focuses on real-world modeling, Object Oriented Software Construction Second Edition (Meyer 1997) very briefly mentions that there are non-real-world classes of objects. From page 219:

"...not all classes correspond to object types of the problem domain. The classes introduced for design and implementation have no immediate counterparts in the modeled system. They are often among the most important in practice, and the most difficult to find."

O-O Analysis and Design Books

By far, Larman's Applying UML and Patterns is the best book on Object Oriented Design. All of my questions have been answered by this book, and my thought process is much clearer given the information presented by Larman. I recommend this book unreservedly to those who want to learn OO, and to those who already use it daily.

Object-Oriented Modeling and Design with UML (Blaha/Rumbaugh 2005): In this second edition, the authors describe a wide range of different type of objects: Domain (real-world), concrete, conceptual, application (UI), implementation, interfaces, boundary classes, and controllers. It's pretty good, but Larman's Applying UML and Patterns is better.

Rumbaugh, et al. 1991 Object-Oriented Modeling and Design: Section 9.10 on page 211 goes over common architectural frameworks. Here the authors show that a combination of the old and the new techniques are required to build a successful system. This includes the possibility of objects that model things that aren't real world. Their coverage is unfortunately rather terse (seven pages), but the idea is definitely there.

Patterns Books

The entire Pattern movement, be it Design Patterns (Gamma et al. 1995), or Architecture Patterns (Pattern-Oriented Software Architecture, Buschmann et al.), is all about creating metaphorical objects. While books on object oriented programming focus on real world models, the pattern movement tells us that it's OK to create metaphorical objects even though they may not map to anything in the real world.

From Gamma et al. 1995 Design Patterns page 11 we have the following two paragraphs:

"Many objects in a design come from the analysis model. But object-oriented designs often end up with classes that have no counterparts in the real world. ... Strict modeling of the real world leads to a system that reflects today's realities but not necessarily tomorrow's. The abstractions that emerge during design are key to making a design flexible."

"Design patterns help you identify less-obvious abstractions and the objects that can capture them. For example, objects that represent a process or algorithm don't occur in nature, yet they are a crucial part of flexible design. ... These objects are seldom found during analysis or even the early stages of design; they're discovered later in the course of making a design more flexible and reusable."

Note how their focus is on flexibility and metaphorical objects. It would be interesting to think this relationship through. I think that it may turn out to be less significant than they imply. As an example, one could model a single credit card and have a rather inflexible e-commerce system. However, using inheritance (not a design pattern), one could model credit cards in general and have a more flexible design. So, the basic real world modeling features of an object oriented language do provide flexibility for today's problems and tomorrow's. Patterns may provide more, but they don't hold a monopoly over flexibility.

Managing Complexity

In my experience, the most common metaphorical objects are used to partition larger classes into more manageable smaller classes. This may have flexibility as a side-effect, but it is usually not my main goal. As an example, one can put all the code necessary for displaying an object on the screen within the object's class. Display methods are a common technique. However, when the display code becomes complex as the class grows, it can be helpful to split the display code out into its own class. This metaphorical display class is commonly called a "View".

View classes provide flexibility when there is more than one way to display an object on the screen. Each way can be encapsulated into its own View class. However, even if this flexibility isn't needed, dividing the code into two smaller classes usually makes the code easier to understand and less cluttered.

All is not perfect, however. Usually display code needs to be aware of the inner workings of a class in order to do its job. As a result, a View class may need access to the internals of the object that it displays. Depending on the implementation language, this might be messy.

Further Thought

I need to do some more research and see how this is handled in other books on O-O. How about Pattern Hatching by Vlissides? Since the focus in patterns is almost always on metaphorical objects, this might expand on the two paragraphs in Design Patterns.

<- Back to my software page.