Protocol and Etiquette are closely related
(photo courtesy of roberto8080 on flickr.com)
This sounds harder than it is, but in some cases it is harder than it sounds!
When you have a few objects and a few messages, it’s not too difficult to keep straight who says what to whom passing which arguments.
When you have a lot of objects and a lot of messages and a lot of different arguments, things can get complicated quickly. This is where patterns of messages come into play.
Message Patterns Reduce Confusion
Patterns of messages occur in two distinct forms: messages between objects, called a Protocol, and messages understood by a particular kind of object, called an Interface. Let’s look at Interfaces first, as they are a bit easier to understand at a glance.
Interfaces
An Interface is a set of messages understood by a particular kind of object. An interface may be as small as a single message, or it may include hundreds of messages [but please don't!]. All objects of the same class automatically have the same interface (via inheritance). But it is possible that objects of different classes may share some common messages, and it is useful – when the programming language supports it – to capture these common messages in an Interface specification. The usefulness comes from being able to specify an interface instead of a class when declaring an object variable; this allows us to use any object that has (“implements”) the interface.
For example, suppose we are working on a game, and we want to be able to move some objects in two dimensions. We may control this movement using a small set of messages like:
- Point MoveLeft(int distance)
- Point MoveRight(int distance)
- Point MoveUp(int distance)
- Point MoveDown(int distance)
Each message specifies how far to move, and returns the new object position for convenience.
We may define an interface, call it iMoveIn2D, that includes these 4 messages, and may create classes that implement this interface.
Now anywhere in our code that we want an object that can move in 2 dimensions, we declare it as if it was an instance of iMoveIn2D, and the compiler will ensure that only objects that implement the appropriate messages will be used.
There’s more to interfaces, and we’re completely ignoring a lot of issues like so-called “duck typing”, but that should be enough to get the gist of what an interface is (a collection of messages) and what it can be used for (ensuring compatibility).
Protocols
A Protocol is when two or more objects exchange messages in particular patterns.
You can think of a protocol as a collection of interfaces, but there may also be a partial ordering on the messages based on time, cause and effect, and/or other dependencies.
For example, when two Americans meet for the first time, the following conversation is common:
| S1: Hello. | S2: Hi. |
| S1: How are you doing? | S2: I am fine, and you? |
| S1: Not too bad. | S2: That’s good. |
We can view this particular exchange of small-talk as the combination of two interfaces:
| Interface 1 | Interface 2 |
|---|---|
| Greeting | Greeting Response |
| General Status Inquiry | General Status Response |
| General Comment |
But note that the protocol represented here includes messages from both interfaces on both sides of the conversation. Also note that the order of the messages depends on the elements of the conversation. It would make no sense to walk up to a stranger and say “I am fine” if they had not asked you how you were doing first!
The notion of a protocol covers everything from a simple handshake to critical-systems checklist exchanges by astronauts to micro-cellular ion exchanges.
That’s enough for now – while a protocol implies at least one interface, the rules governing the order and frequency of messages exchanged may be arbitrarily complex.
This is why learning to think in terms of interfaces and protocols becomes critical as your object-oriented systems become more complex: by reducing the complexity that you have to keep in your head, interfaces and protocols reuse already-established established patterns of messages. So for example, you can think in terms of “database connection protocol” rather than the specific series of messages that are required to negotiate and maintain an active database connection.
About Steven A. Lowe