Form
The patterns are written in electric mo died Portland form. Each b egins with a question (in italics) de-
scribing a problem, followed by one paragraph describing the pattern's context, and a second describing
the forces the pattern resolves. A boldface \
Therefore:
" introduces a summary of the solution (also
italicised) followed by the a description of the solution in detail. Then follows an example of using the
pattern, the patterns consequences (b enets rst, a boldface
But:
, then the liabilities) and nally some
known uses and related patterns.
Patterns ab out Proto cols
Ob jects communicate via proto cols | a program's proto cols are the glue that binds its ob jects together.
The following three patterns describe how ob jects can b e found within protocols.
1 Arguments Ob ject
How can you simplify a complex protocol that has a regular argument structure?
Some ob jects have large and complex protocols with a regular internal structure. For example, a
graphical
View
ob ject will provide proto col for drawing manytyp es of ob jects in many dierentways,
but almost every message will take arguments which specify the colour, stipple, and line thickness to
use when drawing. The same combinations of arguments may occur across many protocols, and as a
result, many arguments may b e passed in parallel through many messages and across many ob jects.
Large protocols are easy to use b ecause they oer a large amount of behaviour to their clients.
Unfortunately, they are often dicult or time consuming to implement, and for client programmers to
learn. Every client of a large protocol dep ends up on the proto col's ne details, such as the names and
arguments required by each message, and these dependencies make large proto cols dicult to change.
Moreover, large proto cols are more likely to be changed than small protocols | adding an eleventh
argument to a message with ten arguments is qualitatively quite dierent to adding a second argument
to a unary message. To quote Alan Perlis:
If you have a procedure with 10 parameters, you probably
missed some
[20].
Therefore:
Make an
Arguments Ob ject
to capture the common parts of the protocol.
In its simplest form, an
Arguments Ob ject
should have one variable for each argument to be
eliminated from the proto col, and the usual messages to access and up date its variables. Change the
protocol and its implementations to accept a single
Arguments Ob ject
in place of the eliminated
arguments, and change the protocol's clients to create
Arguments Ob jects
as required. To support
optional arguments, initialise the
Arguments Ob ject
's variables with default argumentvalues when
it is created.
Example
Consider the proto col provided by a graphical
View
ob ject:
drawRectangleFrom: topLeft to: b ottomRight colour: colour
llRectangleFrom: topLeft to: bottomRight colour: colour
drawOvalFrom: topLeft to: b ottomRight colour: colour
These messages take a number of arguments in common:
topLeft
,
bottomRight
and
colour
. An
Arguments Ob ject
can eliminate these arguments from the proto col. The
Arguments Ob ject
(whichwe will call a
Graphic
) uses three variables to replace the common arguments.
Graphic
's protocol
includes messages to create new
Graphic
ob jects, and to read and write these variables. The
View
's
protocol can be changed to accept a single
Graphic
argument, rather than the three common arguments.
3