Abstract
Design
patterns are becoming increasingly popular as a technique to
describe general solutions to design problems; these
solutions can be reused in the design of different
applications. The basic motivation behind the pattern idea
is that similar design problems appear again and again
in different contexts. A pattern describes an abstract
solution to a design problem which remains incompletely
specified until enough application-dependent information
has been provided.
Each time a
pattern is applied in an application, the methods prescribed
by the pattern must be coded. In general, several
implementations are possible for the same pattern, depending
on the facilities provided by the target programming
language. Features in some languages allow to directly
support some patterns. Other programming languages
do not provide the appropriate mechanisms or constructs
to implement some patterns. Also, the same pattern
can be implemented in very different ways in the same
language.
Object-oriented
programming languages do not provide an adequate support
to directly reflect some important design decisions
in the program code. This limitation causes many well-known
problems during the maintenance phase. The implementation
of patterns with the current object-oriented languages
typically leads to poor legibility and traceability
of patterns in the application code, low reusability
of pattern code, and substantial implementation overhead.
The advantages offered by patterns in the design phase,
like understanding and communicating design, are thus
often lost in the maintenance phase.
These problems can
be solved in various ways, but any solution should
acknowledge that the design should live inside the running
system, and thus drive system behavior at run time. Patterns
can also be seen as a metamodel of the software system,
describing how its various components are structured
to obtain the desired behavior. If a means to represent
and implement such a metamodel at run time was available,
then an explicit trace of the involved design structures
could be deduced from the code itself. The use of computational
reflection techniques appears to be a reasonable
approach.
This work presents
a reflective model that explicitly manages patterns and
their application. A reflective architecture allows the
representation of patterns as first-class entities. The
architecture is composed of two levels: base level and
metalevel. The metalevel represents design patterns while
the base level contains information about the specific
application under development. Meta-objects represent
the patterns involved in the application design. At
run time, the metalevel manipulates the objects at the
base level according to the architecture defined by
the patterns applied in the application. Our approach
offers the advantage of providing an explicit representation
of patterns in such a way that the generic control
structure prescribed by a pattern is reused each time
the pattern is applied. The architecture also fosters
a controlled variation of alternative pattern implementation
by subclassing, as well as the easy incorporation of
new patterns.
.
Cover