Patterns
introduction
teaching
contracts
patterns
events
examples
foundations
conclusions
references
The notion of 'patterns' is relatively new
in the study of object-oriented software development.
Patterns are characterized in [GOF]
as cristalized design experience,
and as such the study of patterns provides
an answer to one of the fundamental problems
in object-oriented software development:
"What is good object-oriented design?"
Problem
The majority of students (still) enter the field
of object-oriented programming and object-oriented
system development from a background which is
dominated by imperative programming and possibly
modular programming.
Due to this background, some have difficulties
in seeing how the actual computation
in an object-oriented system proceeds,
that is where the 'real work' is done.
In particular this holds when the work is divided
over multiple objejcts, as is often the case
when for example a framework for developing
graphical user interfaces is employed.
Teaching 'patterns' requires that a rationale
for patterns is given, and consists
of clarifying what kinds of objects are involved
and how control is distributed over
these objects.
Initially, students seem to have difficulty
in reasoning about the interaction between objects
in such an abstract fashion.
Background
The notion of patterns is closely related to the
notion of idioms, as originally introduced
in [Coplien].
Idioms may be regarded as recipes that can be used to solve
particular programming problems,
such as for example those related to memory managent.
Among the idioms discussed in [Coplien]
we have the concrete data type idiom
(which gives guidelines for implementing user-defined data
types that behave like built-in data types),
the handler/body or envelope/letter
idiom (that can be used to separate the interface and
realization of a data type),
and the virtual constructor idiom
(that allows for selecting runtime the actual
type of a newly created object).
Despite the availability of numerous methods
of (object-oriented) design and software development,
there is a need for actual examples demonstrating how
an 'object-oriented' solutions looks like in practice.
As an example, [OMG] reports the benefits and pitfalls
of an object-oriented approach in developing business-applications.
Project reports, however, do generally not provide
sufficiently detailed information with
regard to design decisions.
Patterns were introduced in [GOF] as a means
to capture design information
that allows that information to be (re)used
in similar projects.
The patterns presented in [GOF] result from
reflecting on the experience with the design and
implementation of the Interviews [Interviews] and ET++ [ET] toolkits.
They cover issues with respect to the realization
of various document and widget types,
search and manipulation strategies,
information updates, and flexible user interaction.
(Among the patterns discussed in [GOF], we find\
the Factory, Visitor, Observer and Interpreter
patterns in particular very useful.)
Basic metaphor
Due to the variety of patterns, a single basic metaphor
is hard to come up with.
Object interaction is (almost) as complex as human interaction!
There is a close analogy between the need for
idioms and patterns and the use of natural language.
Generally speaking, applying the (grammar) rules
is in itself not sufficient, since actual usage
is determined too a large extent by habits
and conventions that have proven their worth.
Idioms and patterns provide a repertoire which may
be used as a cookbook containing recipes for a variety
of meals including your favorite, hopefully.
A common characteristic of patterns
is the 'objectification' of behavior.
Whereas the original guidelines in OO design
hinted at identifying objects corresponding
to real world entities [Booch],
patterns employ objects to characterize behavioral
properties.
The rationale behind this use of objects
is simply to gain flexibility and (hence)
to master the complexity of both
the application domain and the development platform.
Realization
Not surprisingly,
many of the idioms described in [Coplien]
are employed in the actual realization of the
patterns described in [GOF].
In particular, the handler/body idiom
is frequently used.
However, the realizations of patterns presented
in [GOF] seem to require laborious programming
and generally result in a proliferation of class types.
Moreover, they require public knowledge
of the interface of the implementation classes
introduced.
As sketched in [DejaVu], the implementation
classes may be completely hidden,
when employing semi-abstract classes, explicit delegation and
virtual constructors.
Comments
The body of literature is steadily growing.
Of particular interest are patterns
(and pattern catalogs) aiming at a particular application area,
as for example presented in [PLOP].
introduction
teaching
contracts
patterns
events
examples
foundations
conclusions
references