UML Designer User's Guide


Protocols

By now we have developed a fairly good idea of the requirements of our system, at least good enough for a first pass. We understand what use cases it must support, we've identified the actors and things, and we know what their responsibilities are. The next step is to begin analysis of the system, in order to start figuring out how we will satisfy these requirements.

At this point, your first instinct might be to begin writing code, implementing things as objects and responsibilities as methods. A better approach, however, is to more closely examine the responsibilities of the things in the system in order to understand how they work together. We can do this through the use of protocols. (In fact, you can often do both: go ahead and sketch out some classes, but then come back to analysis and use protocols to make sure the design is watertight.)

Rigorous use of protocols guarantees substitutability: any class conforming to a given protocol (or to one refining that protocol) can be substituted for any other class conforming to that same protocol. If a class conforms to the expected protocol, type mismatches cannot happen. In Smalltalk terms, this means never getting a doesNotUnderstand message.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]