Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
This is the fifth installment in a series of articles about fundamental object-oriented (OO) concepts. The material presented in these articles is partially excerpted from the second edition of my book, The Object-Oriented Thought Process, 2nd edition. The Object-Oriented Thought Process is intended for anyone who needs to understand the basic object-oriented concepts before jumping into the code.
As we saw in last month’s article, one of the first thought process skills you must master is how to actually think in terms of objects. This may be easier than you think because in the real world you do think in terms of objects. It is simply a matter of changing your software development paradigm to think in terms of objects rather than thinking of a program as simply code and data. In this installment, we will further discuss how you start thinking in terms of objects.
Using Abstract Thinking when Designing Interfaces
One of the main advantages of OO programming is that classes can be reused. In general, reusable classes tend to have interfaces that are more abstract than concrete. Concrete interfaces tend to be very specific, whereas abstract interfaces are more general. However, simply stating that a highly abstract interface is more useful than a highly concrete interface, although often true, is not always the case.
It is possible to write a very useful, concrete class that is not at all reusable. This happens all the time, and there is nothing wrong with it in some situations. However, we are now in the design business, and want to take advantage of what OO offers us. So, our goal is to design abstract, highly reusable classes—and to do this we will design highly abstract user interfaces. To illustrate the difference between an abstract and a concrete interface, let’s create a taxi object. It is much more useful to have an interface such as “drive me to the airport” than to have separate interfaces such as “turn right,” “turn left,” “start,” “stop,” and so on, because as illustrated in Figure 1, all the user wants to do is get to the airport.
Figure 1: An abstract interface.
When you emerge from your hotel, throw your bags into the back seat of the taxi and get in, the cabbie will turn to you and ask, “Where do you want to go?” You reply, “Please take me to the airport.” (This assumes, of course, that there is only one major airport in the city. In Chicago you would have to say, “Please take me to Midway Airport” or “Please take me to O’Hare.”) You might not even know how to get to the airport yourself, and even if you did, you wouldn’t want to have to tell the cabbie when to turn and which direction to turn, as illustrated in Figure 2. How the cabbie implements the actual drive is of no concern to you, the passenger. (Of course, the fare might become an issue at some point, if the cabbie cheats and takes you the long way to the airport.)
Now, where does the connection between abstract and reuse come in? Ask yourself which of these two scenarios is more reusable, the abstract or the not-so-abstract? To put it more simply, which phrase is more reusable: “Take me to the airport,” or “Turn right, then right, then left, then left, then left?” Obviously, the first phrase is more reusable. You can use it in any city, whenever you get into a taxi and want to go to the airport. The second phrase will only work in a specific case. Thus, the abstract interface “Take me to the airport” is generally the way to go for a good, reusable OO design, whose implementation would be different in Chicago, New York, or Cleveland.
Figure 2: A not-so-abstract interface.
Giving the User the Minimal Interface Possible
When designing a class, the rule of thumb is to always provide the user with as little knowledge of the inner workings of the class as possible. To accomplish this, follow these simple rules:
- Give the users only what they absolutely need. In effect, this means the class has as few interfaces as possible. When you start designing a class, start with a minimal interface. The design of a class is iterative, so you will soon discover that the minimal set of interfaces might not suffice. This is fine. It is better to have to add an interface because users really need it than to give the users more interfaces than they need.
- For the moment, let’s use a hardware example to illustrate our software example. Imagine handing a user a PC box without a monitor or a keyboard. Obviously, the PC would be of little use. You have just provided the user with the minimal set of interfaces to the PC. Of course, this minimal set is insufficient, and it immediately becomes necessary to add interfaces.
- Public interfaces are all the users will ever see. You should initially hide the entire class from the user. Then, when you start using the class, you will be forced to make certain methods public—these methods thus become the public interface.
- It is vital to design classes from a user’s perspective and not from an information systems viewpoint. Too often, designers of classes (not to mention any other kind of software) design the class to make it fit into a specific technological model. Even if the designer takes a user’s perspective, it is still probably a technician user’s perspective, and the class is designed with an eye on getting it to work from a technology standpoint, and not from ease of use for the user.
- Users are the ones who will actually use the software. Make sure when you are designing a class that you go over the requirements and the design with the people who will actually use it—not just developers. The class will most likely evolve and need to be updated when a prototype of the system is built.
Determining the Users
Let’s look again at the taxi example. We have already decided that the users are the ones who will actually use the system. This said, the obvious question is “Who are the users?”
The first impulse is to say the customers. This is only about half right. Although the customers are certainly users, the cabbie must be able to successfully provide the service to the customers. In other words, providing an interface that would, no doubt, please the customer, such as “Take me to the airport for free,” is not going to go over well with the cabbie. Thus, in reality, to build a realistic and usable interface, both the customer and the cabbie must be considered users.
For a software analogy, consider that users might want a programmer to provide a certain function. However, if the programmer finds the request technically impossible, it is not a reasonable request.
In short, any object that sends a message to the taxi object is considered a user (and yes, the users are objects, too). Figure 3 shows how the cabbie provides a service.
Note: The cabbie is most likely an object as well.
Object Behavior
Identifying the users is only a part of the exercise. After the users are identified, you must determine the behaviors of the objects. From the viewpoint of all the users, begin identifying the purpose of each object and what it must do to perform properly. Note that many of the initial choices will not survive the final cut of the public interface. These choices are identified by gathering requirements by using various methods such as UML use cases.
Figure 3: Providing services.
Environmental Constraints
In their book Object-Oriented Design in Java, Gilbert and McCarty point out that the environment often imposes limitations on what an object can do. In fact, environmental constraints are almost always a factor. Computer hardware might limit software functionality. For example, a system might not be connected to a network, or a company might use a specific type of printer. In the taxi example, the cab cannot drive on a road if a bridge is out, even if it provides a quicker way to the airport.
Identifying the Public Interfaces
With all the information gathered about the users, the object behaviors, and the environment, you need to determine the public interfaces for each user object. So, think about how you would use the taxi object:
- Get into the taxi.
- Tell the cabbie where you want to go.
- Pay the cabbie.
- Give the cabbie a tip.
- Get out of the taxi.
What do you need to do to use the taxi object?
- Have a place to go.
- Hail a taxi.
- Pay the cabbie money.
Initially, you think about how the object is used and not how it is built. You might discover that the object needs more interfaces, such as “Put luggage in the trunk” or “Enter into a mindless conversation with the cabbie.” Figure 4 provides a class diagram that lists possible methods for the Cabbie class.
Figure 4: The methods in a cabbie class.
As is always the case, nailing down the final interface is an iterative process. For each interface, you must determine whether the interface contributes to the operation of the object. If it does not, perhaps it is not necessary. Many OO texts recommend that each interface model only one behavior. This returns us to the question of how abstract we want to get with the design. If we have an interface called enterTaxi(), we certainly do not want enterTaxi() to have logic in it to pay the cabbie. If we do this, then not only is the design somewhat illogical, but there is virtually no way that a user of the class can tell what has to be done to simply pay the cabbie.
Identifying the Implementation
After the public interfaces are chosen, you need to identify the implementation. After the class is designed and all the methods required to operate the class properly are in place, the issue tends to be an either/or proposition.
|
What is Implementation? Implementation includes the code within ALL methods. Thus, you may have a signature that represents a public interface (such as “drive me to the airport”). However, the code inside the method is actually hidden from the user and is thus considered part of the interface. Generally, all code is part of the implementation. |
Technically, anything that is not a public interface can be considered the implementation. This means that the user will never see any of the methods that are considered part of the implementation, including the method’s signature (which includes the name of the method and the parameter list), as well as the actual code inside the method. The implementation is totally hidden from the user. In fact, the code within public methods is actually a part of the implementation because the user cannot see it. (The user should only see the calling structure of an interface—not the code inside it.)
The beauty of this approach is that, theoretically, anything that is considered the implementation can change without affecting how the user interfaces with the class. This assumes, of course, that the implementation is providing the answers the user expects.
Whereas the interface represents how the user sees the object, the implementation is really the nuts and bolts of the object. The implementation contains the code that represents that state of an object.
Conclusion
In the past two articles of this series, we have explored several areas that can get you started on the path to thinking in an OO way. Remember that there is no firm list of issues pertaining to the OO thought process. Doing things in an OO way is more of an art than a science. Try to think of your own ways to describe OO thinking.
References
Fowler, Martin. UML Distilled. Addison-Wesley Longman, 1997.
Gilbert, Stephen, and Bill McCarty. Object-Oriented Design in Java. The Waite Group, 1998.
Meyers, Scott. Effective C++. Addison-Wesley, 1992.
About the Author
Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a part of the Information Technology department, teaching programming languages such as C++, Java, and C# .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management.
The articles in this series are adapted from The Object-Oriented Thought Process (published by Sams Publishing). Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb’s Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.
