< Day Day Up > |
Giving the User the Minimal Interface PossibleWhen 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:
Determining the UsersLet'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, like "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 2.6 shows how the cabbie provides a service. Figure 2.6. Providing services.
Looking Ahead The cabbie is most likely an object as well. Object BehaviorIdentifying 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 using various methods such as UML use cases. Environmental ConstraintsIn 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 InterfacesWith 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:
What do you need to do to use the taxi object?
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 2.7 provides a class diagram that lists possible methods for the Cabbie class. Figure 2.7. 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 ImplementationAfter 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. 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 interfacenot the code inside it.) This means that, theoretically, anything that is considered the implementation might 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. |
< Day Day Up > |