Previous | Table of Contents | Next |
All the fundamental features of object-oriented programming can be identified in this simple and common situation. The mechanism used to solve the previous problem involved finding an appropriate agent (in object-oriented terms, an object) and giving to this agent a message that describes the request. In this scenario, the agent is the florist Flo, and the message is the selection of flowers desired and the addresses of the person to which the flowers should be sent. The sender does not knownor does he need or want to knowthe exact details concerning how the request will be carried out. Of course, the florist might well deliver a slightly different message to another florist in another city, who has earlier communicated with a flower wholesaler, and who now must communicate with a delivery person, and so on. Thus, an entire community of individuals must cooperate with each other to satisfy my request.
If we rephrase this approach to problem solving in more technical terms, it produces a situation that applies to object-oriented programming. In this case, action is initiated by the transmission of a message to an agent (an object) that is responsible for the action. The message encodes the request for an action and is accompanied by any additional information (arguments) needed to carry out the request. The receiver is the agent to whom the message is sent. If the receiver accepts the message, it accepts the responsibility to carry out the indicated action. In response to a message, the receiver performs some method to satisfy the request.
There is an ironic twist to viewing programming in these client/server terms. People are generally accustomed to depending on others for the advancement of their own goals. It is very much human nature that when a person is faced with a new problem to solve, one of the first questions he asks himself is who he can call on to help him with the problem at hand. Programmers, on the other hand, tend to be a fiercely independent lot. They most often are distrustful of any code they did not themselves have a hand in creating. Thus, although the object-oriented perspective of structuring a problem as a cooperating community of interacting agents might seem natural to novices, long-time expert programmers sometimes have a much more difficult time. Programmers must consciously work to resist the temptation to write everything from scratch and must be continually encouraged to make use of existing components and existing solutions to common problems.
In considering the scenario describing my interaction with the local florist, an important feature to note is that the florist is described by the services she provides, not by the actions she takes in the performance of her duties. In computer terms, this is called information hiding. I dont really know how my request will be processed, I dont really care to know. All I know is that my florist has agreed to the responsibility for providing this service, and that, having accepted my message, the florist will take the necessary actions.
The link between message and action in both the real world and in the object-oriented world is less binding than, for example, the link between a function name and a function implementation in a conventional programming language. This is because a message is transmitted to a receiver, and the interpretation of the message (that is, the actions to be performed) is determined entirely by the receiver. As a result, different objects might understand the same messages but might react differently. For example, an executive can give the same message to his secretary that he gave to the florist (namely, the address of the friend, the type of flowers desired, and the credit card number for payment) and will expect that the desired outcome will be achieved. But the actions that the secretary performs might be very different from those of the local florist. Thus the same message can elicit two entirely different behaviors.
Thus, the idea of messages in object-oriented programming is intimately tied to the concept of information hiding. The difference between viewing software in traditional, structured terms and viewing it from an object-oriented perspective can be summarized by a twist on a well-known quote:
Ask not what you can do to your data structures, but rather ask what your data structures can do for you.
Although I have dealt with Flo the florist only a few times, I have a rough idea of the behavior I can expect when I go into her shop and present her with my request. I am able to make certain assumptions because I have some information about florists in general, and I expect that Flo, being an instance of this category, will fit the general pattern. We can use Florist to represent the category (or class) of all florists. Let us incorporate these notions into our next principle of object-oriented programming:
All objects are instances of a class. The method invoked by an object in response to a message is determined by the class of the receiver. All objects of a given class use the same method in response to similar messages.
The same idea is incorporated in object-oriented programming languages. In a painting application, for example, I might have several instances of a general class Rectangle being displayed in a window. Each rectangle is in a sense different; each might have a different color or shape, for example. Yet each is also similar to the others; each could be, for example, moved or resized using the same commands. The notion of a class lets me describe the common features of the concept, while still allowing each object to have some sense of individuality.
Previous | Table of Contents | Next |