Furthering the Object-Oriented Mindset, Page 2
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.
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.
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.