THE ADVANCED COMPUTING SYSTEMS ASSOCIATION

The following paper was originally published in the 5th USENIX Conference on Object-Oriented Technologies and Systems (COOTS '99)

San Diego, California, USA, May 3–7, 1999

Filters as a Language Support for Design Patterns in Object-Oriented Scripting Languages

Gustaf Neumann and Uwe Zdun University of Essen, Germany

© 1999 by The USENIX Association All Rights Reserved

Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.

For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org

Filters as a Language Supp ort for Design Patterns in

Ob ject-Oriented Scripting Languages

Gustaf Neumann and Uwe Zdun

Information Systems and Software Techniques

University of Essen, Germany

fgustaf.neumann,[email protected]

1 Intro duction Abstract

1.1 Scripting Languages

In applications, where the emphasis lays on the

exible reuse of comp onents, scripting languages,

Scripting languages are designed for glueing soft-

like Tcl Tool Command Language [25], are very

ware comp onents together. Such languages pro-

useful for a fast and high-quality development of

vide features like dynamic extensibility and dynamic

software. The application developmentin scripting

typing with automatic conversion that make them

languages di ers fundamentally from the develop-

well suited for rapid application development. Al-

ment in systems programming languages [26] like

though these features entail runtime p enalties, mo d-

C, C++ or Java, where the whole system is de-

ern CPUs are fast enough to execute even large ap-

velop ed in a single language. A scripting language

plications in scripting languages eciently.

followsatwo-level approach, distinguishing b etween

comp onents reusable software mo dules and glue-

ing co de, which is used to combine the comp onents

Large applications typically entail complex pro-

according to the application needs. This two level

gram structures. Ob ject-orientation o ers the

approachleads to a rapid application development

means to solve some of the problems caused bythis

[26].

complexity, but fo cuses only on entities up to the

size of a single class. The ob ject-oriented design

Scripting languages are typically interpreted and

community prop oses design patterns as a solution

use a dynamic typ e system with automatic conver-

for complex interactions that are p o orly supp orted

sion. The application develop er uses a single data

by current ob ject-oriented programming languages.

typ e strings for the representation of all data.

In order to use patterns in an application, their im-

Therefore, the interfaces of all comp onents t to-

plementation has to b e scattered over several classes.

gether automatically and the comp onents can be

This fact makes patterns hard to lo cate in the ac-

reused in unpredicted situations without change.

tual co de and complicates their maintenance in an

The disadvantages of scripting languages are a loss in

application.

eciency e.g. for dynamic conversions and metho d

lo okup and the lack of reliability prop erties of a

static typ e system [18]. But these disadvantages can

This pap er presents a general approach to com-

b e comp ensated to a certain degree:

bine the ideas of scripting and ob ject-orientation in

a way that preserves the bene ts of both of them.

 For several application tasks, the loss of e- It describ es the ob ject-oriented scripting language

ciency is not necessarily relevant, b ecause the XOTcl Extended OTcl, which is equipp ed with

time critical co de can be placed into comp o- several language functionalities that help in the im-

nents written in ecient systems programming plementation of design patterns. We intro duce the

languages. Only the co de to control these com- lter approach whichprovides a novel, intuitive, and

ponents is kept in the highly exible scripting powerful language supp ort for the instantiation of

language. large program structures like design patterns.

to manipulate through the evolving non-lo cality in  Since the comp onents are typically written in

the structures. They involve a pattern-like matching a language with a static typ e system the relia-

of similar b ehavior in long-term memory. The string bility argument applies only on the glue co de,

as an uniform and exible interface instead of the used to combine the comp onents. To address

use of p olymorphism makes the ob jects easier to b e these remaining problems we have integrated

put together. They get one unique b ehavior and one an assertion concept based on pre- and p ost-

unique interface. They may b e used in di erent situ- conditions and invariants see [24].

ations di erently, but the required knowledge ab out

the ob ject remains the same.

Since Tcl is designed for glueing comp onents to-

gether, it is equipp ed with appropriate functionali-

These arguments accountfor the glueing idea of

ties, such as dynamic typing, dynamic extensibility

the scripting language in the scop e of a single class

and read/write introsp ection. Many ob ject-oriented

and its environment. This scop e of a \program-

Tcl-extensions do not supp ort well these abilities in

ming in the small" is the strength of current ob ject-

their language constructs. They integrate foreign

oriented language concepts. Their weakness is the

concepts and syntactic elements mostly adopted

\programming in the large", where all comp onents

from C++ into Tcl see e.g. [15, 9]. Even less

of a system have to be con gured prop erly. The

appropriate is the encouraged programming style in

concepts only provide a small set of functionalities

structured blo cks and the corresp onding rigid class

that work on structures larger than single classes,

concept, which sees classes as write-once, unchange-

e.g. from languages likeJava or C++ the following

able templates for their instances. This concept is

are known:

not compatible with the highly dynamic prop erties

of the underlying scripting language.

 virtual prop erties are used to de ne additional

ob ject- and class-prop erties,

1.2 Scripting and Ob ject Orientation

 abstract classes sp ecify formal interfaces and re-

quirements for a set of classes,

The three most imp ortant bene ts of ob ject-

orientation are encapsulation of data and op erations,

 parametric class de nitions are used for di er-

co de reuse through inheritance, and p olymorphism.

entdatatyp es on one class-layout.

These should help to reduce development time, to

increase software reuse, to ease the maintenance of

Beneath such language constructs, metho dical ap-

software and to solve many other problems.

proaches, like frameworks, exist. Since they are

But these claims are not undoubted: For example

co ded using conventional language constructs the

Hatton [11] argues that the non-lo cality problems

problems due to the language insuciencies are not

of inheritance and p olymorphism in languages, like

eliminated. The main insuciency is that classes

C++,donot match the mo del of the human mind

and ob jects are relatively small system-parts com-

well.

pared to an entire, complex system. Therefore, the

wish for a language construct, which maps such a

Encapsulation lets us think ab out an ob ject in iso-

large structure to an instantiable entity of the pro-

lation; this is related to the notion of manipulating

gramming language, arises.

something in short-term memory exclusively. There-

fore, encapsulation ts the human reasoning. Since

in scripting languages a form of co de reuse is already

1.3 OTcl { MIT Ob ject Tcl

provided through reusable comp onents, the foremost

reason for the use of ob ject-orientation in a scripting

We b elieve OTcl [32] is an extraordinary ob ject-

language is the encapsulation. For that reason, the

oriented scripting language which supp orts several

inheritance problem also seems less con icting, be-

features for handling complexity. It preserves and

cause the inheritance is mainly used to structure the

extends the prop erties of Tcl likeintrosp ection and

system and to put the comp onents together prop-

dynamic extensibility. Therefore, weusedOTcl as

erly. Inheritance in scripting applications normally

the starting p oint for the developmentof XOTcl.

do es not lead to large and complex classes that are

strongly dep endentoneach other.

In OTcl each ob ject is asso ciated with a class.

Classes are ordered by the sup erclass relationship Hatton [11] criticizes the p olymorphism in C++

in a directed acyclic graph. The ro ot of the class as damaging, b ecause ob jects b ecome more dicult

with do cumentation and usage constraints in the hierarchy is the class Object that contains the meth-

implementation as well. ods available in all instances. A single ob ject can

be instantiated directly from this class. In OTcl

classes are sp ecial ob jects with the purp ose of cre-

2.1 Language Supp ort for Design Pat-

ating and managing other ob jects. Classes can be

terns

created and destroyed dynamically like regular ob-

jects. Classes contain a rep ository of instance meth-

Most e orts in the literature of design patterns

o ds \instpro cs" for the asso ciated ob jects and pro-

collect and catalog patterns. These activities are

vide a sup erclass relationship that supp orts multiple

very imp ortant, since they are the basis for new soft-

inheritance.

ware architectures using design patterns. Soukup

Since a class is a sp ecial managing kind of ob ject,

[30] remarks that this basic work is not yet ended.

it is managed by a sp ecial class called \meta-class"

which manages itself . The meta-class is used to

Most authors present design patterns as guidelines

create and to instantiate ordinary classes. By mo di-

for the design. When they are used in the design

fying meta-classes it is p ossible to change the b ehav-

phase, the abstract pattern has to be transformed

ior of the derived classes widely. All inter-ob ject and

into a concrete implementation for each usage. A

inter-class relationships are completely dynamic and

basic idea of this pap er is to allow one to co de a

can be changed at arbitrary times with immediate

pattern once in an abstract way e.g. for a pattern-

e ect.

library and reuse it later in a sp ecialized manner.

The gained advantage is that patterns b ecome ab-

stract entities of the design pro cess as well as of the

implementation. This is similar to the use of the

2 Design Patterns in Scripting Lan-

design pro cess entities \ob ject" and \class" which

guages

are also entities in ob ject-oriented programming lan-

guages.

The complexity of many large applications is

There are only a few e orts in the direction of

caused by the combination of numerous, often in-

language supp ort for design patterns so far. We

dep endently develop ed comp onents, which have to

b elieve that one reason for this lack of supp ort is

work in concert. Typically, many classes are in-

due to the targeted languages. Conventional ob ject-

volved, with di erent kinds of non-trivial relation-

oriented programming languages, like C++, o er no

ships, like inheritance, asso ciations, and aggrega-

supp ort for repro duction of larger structures than

tions. Design patterns provide abstractions over

classes like design patterns. Therefore, it is nearly

reusable designs, that can typically b e found in the

imp ossible to get a sucient repro duction of such

\hot sp ots" [28]ofsoftware architectures. Patterns

1

structures as an entity . But there are more reasons

are designed to manage complexity by merging in-

[4], why language supp ort for design patterns should

terdep endent structures into one abstract design

b e improved:

entity.

Design patters are considered increasingly often as

 Traceability: The pattern is scattered over the

reusable solutions for general problems. Sp ecialized

ob jects and, therefore, hard to lo cate and to

instances of design patterns can b e used in a diver-

trace in an implementation.

sity of applications. Soukup [30] de nes a pattern

as follows:

 Self-Problem: The implementation of several

patterns requires forwarding of messages, e.g.

\A pattern describ es a situation in whichsev-

an ob ject A receives a message and forwards

eral classes co op erate on a certain task and

it to an ob ject B . Once the message is for-

form a sp eci c organization and communica-

warded, references to self refer to the delegated

tion pattern."

ob ject B , rather than to the original receiver A.

Design patterns are collected in pattern catalogs

known as the self-problem [17].

[10, 6]. Typically, these catalogs contain general

 Reusability: The implementation of the pattern

patterns, but there are also catalogs which collect

must b e reco ded for every use.

domain sp eci c patterns. In this pap er, we see a de-

sign pattern as an abstract entity with normative,

1

Soukup [30] shows that some design patterns can b e im-

constructive and descriptive prop erties, that is iden-

plemented as classes in C++ using friend, but Bosch [4]

ti ed in the design pro cess and has to b e preserved p oints out that these are only a few.

 Implementation Overhead: The pattern imple- geted on complex software architectures and pat-

mentation requires several metho ds with only terns. In particular, we added:

trivial b ehavior, e.g. metho ds solely de ned for

message forwarding.

 nested objects based on Tcl's namespaces to a

reduce the interference of indep endently devel-

Pree [28]identi es seven meta-patterns that de ne

op ed program structures, b to supp ort nested

most of the patterns of Gamma et.al. [10]. This indi-

classes and c to provide dynamic aggregations

cates that it is p ossible to nd language constructs,

of ob jects.

which are able to represent all structures de nable

by these meta-patterns. In this work, we presentthe

 assertions to reduce interface problems, to im-

lter as such a language construct. prove the reliabilityweakened by dynamic typ-

ing and, therefore, to ease the combination of

many comp onents,

2.2 Language Supp ort for Design Pat-

terns in XOTcl

 meta-data to provide self-do cumentation of ob-

jects and classes,

In the following sections, we describ e the lan-

 per-object mixins as a exible means to give

guage supp ort for design patterns we have devel-

an ob ject access to several di erent addition-

op ed. We intro duce our ideas with examples from

classes, whichmaybechanged dynamically, and

the language Extended OTcl XOTcl, pronounced

nally,

exotickle  which is an extension of OTcl,butwegive

no intro duction to the language. Figure 1 shows the

 lters as a means of abstractions over metho d

relationship b etween XOTcl and OTcl and lists im-

invo cations to implement patterns see Section

p ortant prop erties of OTcl. 2.3.

Tcl

rst three extensions are variations of known

namespaces Tcl The

hwehave adopted in a dynamical and introspection concepts, whic

extensibility

introsp ective fashion, the last two are both novel

approaches. In [24,33]we describ e all these features

detail, in this pap er we solely describ e the lter

Extended OTcl ... in h. New Functionalities: Adopted from OTcl: Other approac dynamic aggregations object-orientation: Extensions nested classes Tcl encapsulation

assertions inheritance

The Filter Approach meta-data 2.3 per-object mix-ins multiple inheritance filter method chaining meta-classes

read/write introspection

Wehave p ointed out that the realization of design

dynamic extensibility

patterns as entities is avaluable goal and that the

ob ject-oriented paradigm is not able to achievethis

through classes alone. OTcl o ers a means for the

Figure 1: Language Extensions of XOTcl

instantiation of large structures, like entire design

patterns: the meta-classes. But in pure OTcl only

Tcl and OTcl already havemany prop erties that

a few patterns are instantiable this way e.g. the

are very helpful for the implementation of patterns.

abstract factory as in [33], without su ering from

Dynamic typing, as stated ab ove, eases the man-

the problems stated in Section 2.1. Typically,these

agement of highly generic structures. The de nition

patterns do not rely on a delegation or aggregation

of pattern parts as meta-classes makes them enti-

relationship.

ties of the programming language and instantiable

with the name of the pattern. Introsp ection allows

Even though ob ject-orientation orders program

self-awareness and adaptive programs, and simpli-

structures around the data, ob jects are character-

es the maintenance of relationships such as aggre-

ized primarily by their b ehavior. Ob ject-oriented

gations. Per-ob ject sp ecialization eases implemen-

programming style encourages the access of encap-

tation of single ob jects with varying behavior, e.g.

sulated data only through the metho ds of the ob ject,

non-sp ecializable singleton patterns.

since this allows data abstractions [31]. A metho d

invo cation can b e interpreted as a message exchange In addition to the abilities of OTcl, we imple-

between the calling and the called ob ject. Therefore, mented in XOTcl new functionality sp ecially tar-

metho d is called, the next call invokes the message ob jects are only traceable at runtime through their

chaining, and the post-part contains the actions to message exchanges. At this p oint the lters can b e

b e executed b efore the lter is left. In this example applied, which are able to catch and manipulate all

the pre- and p ost-parts are simple printing state- incoming and outgoing messages of an ob ject.

ments, but in general they may b e lled with arbi-

A lter is a sp ecial instance metho d registered

trary XOTcl-statements. The distinction between

for a class C . Every time an ob ject of class C

the three parts is just a naming convention for ex-

receives a message, the lter is invoked auto-

planation purp oses.

matically.

Filter_3 message (c) filter-chain Filter_2

Class A

lter is implemented as an ordinary instance

A message (b) Filter_1 }

metho d instproc registered on a class. When the

lter is registered, all messages to ob jects of this

must go through the lter, b efore they reach class Class A

message (a)

destination ob ject. The lter is free in what their o0 pre-part

call a1

it do es with the message, esp ecially it can a pass

post-part result

the potentially mo di ed message to other lters

and nally to the ob ject, or b it can redirect it to

another destination, or c it can decide to handle

the message solely.

The forward passing of messages is implemented

Figure 2: Cascaded Message Filtering

as an extension of the next primitiveof OTcl. next

implements metho d chaining without explicit nam-

The following extension of the intro ductory exam-

ing of the \mixin"-metho d. It mixes the same-

ple shows how to apply more than one lter, which

named sup erclass metho ds into the current metho d

are cascaded through next see Figure 2. In this

mo deled after CLOS [5]. All classes are ordered in

extended example a lter chain consisting of two l-

a linear next-path. At the p ointmarked by a call to

ters is used. Again next forwards messages to the

next the next shadowed metho d on this next-path is

remaining lters in the chain or to the actual called

searched and, when it is found, it is mixed into the

metho d. The metho d filter registers the list of l-

execution of the current metho d.

ters to b e used.

In XOTcl, a single class mayhave more than one

A instproc Filter-2 args {

puts "only a pre-part in [self proc]"

lter. All the lters registered for a class form an

next

ordered lter chain. Since every lter shadows all

}

A instproc Filter-3 args {

instance metho ds, next app ears as a suitable mech-

next

anism to call the next lter in the chain. When all

puts "only a post-part in [self proc]"

}

lters are worked through, the actual called metho d

A filter {Filter-1 Filter-2 Filter-3}

is invoked. By placement of the next-call, a lter

de nes if and at which point the remaining lters

When an instance a1 of class A receives a message,

and nally the actual metho d-chain are invoked.

like\a1 set x 1", it pro duces the following output.

The next-call in the last lter Filter-3 of the chain

Class A

A instproc Filter-1 args {

invokes the actual called metho d set.

puts "pre-part of [self proc]" ; pre part

next ; next call

pre-part of Filter-1

puts "post-part of [self proc]" ; post part

only a pre-part in Filter-2

}

only a post-part in Filter-3

A filter Filter-1

post-part of Filter-1

Aa1

a1 set x 1

The filter metho d can be used to remove lters

This intro ductory example de nes a single class

dynamically as well. E.g. the lters Filter-1 and

and a single lter instpro c. It registers the lter

Filter-3 can b e removed by:

for the class using the filter instance metho d. An

A filter Filter-2

ob ject a1 is created. In the last line the prede ned

set metho d is invoked. Automatically the registered On each class the lters are invoked in the order

lter Filter-1 of class A receives the message set. sp eci ed by the filter instance metho d. Toavoid

The lter instpro c consists of three optional parts: circularities all lters which are currently active {

The pre-part consists of the actions b efore the actual that means that the currentcallisinvoked directly

Language Supp ort for Design Pat- Class Object 3

3

terns using Filters 4 pre-part

Class A

Nowwe present a systematic approachhow lters

a1

t design patterns. In gen- 2 can b e used to implemen

5

eral, lters are very exible and well-suited for im-

Class B

plementing patterns in various creativeapproaches.

Filter Chain of b2 Class B

1 b1

3.1 Applying Filters on Meta-Patterns 6 b1 set x 10

post-part

In [28] Pree has identi ed meta-patterns as struc-

tures underlying several design pattern. They sub-

Figure 3: Filter Inheritance

divide the pattern into a general, generic pattern-

class called template  and a class which serves as

or indirectly from a lter instpro c { are temp orarily

an anchor for the application sp eci c details called

left out of the lter chain. Filter chains can also b e

hook .

combined through multiple inheritance using next.

lters are normal instpro cs they may them- Since Hook Class Template Class

href

es b e sp ecialized through inheritance. When the

selv Operation T-Operation

end of the lter chain of the ob ject's class is reached,

the lter chains of the sup er-classes are invoked us-

Specialized Hook Class ing the same precedence order as for inheritance.

Operation

This is demonstrated by the example displayed in

Figure 3. B is a sub class of A with two instances b1

Figure 4: The 1:1 Meta-Pattern [28] with a Sp ecial-

and b2. Both instances are ltered with the chains

ized Ho ok

registered on B, A and Object. The invocation b1 set

x 10 results in the next-path shown in Figure 3.

Figure 4 shows a simple meta-pattern, that is

based on a 1:1 asso ciation. It separates the sp e-

Class B -superclass A

B instproc Filter-B args {

cializations of a ho ok class from a template class.

puts "entering method: [self proc]"

This is just an example pattern to give an idea of

next

}

ho ok and template. It is obvious that many ob ject-

Bb1;Bb2

oriented structures, like several design patterns in

B filter Filter-B

b1 set x 10

[10,6], are based up on this meta-structure.

Filters have richintrosp ection mechanisms. Each

The metho ds of the template implement the

class may be queried using the introsp ection

generic part of the structure and invoke the ho ok

metho d info filters what lters are currently in-

metho ds. The abstract ho ok forms a common in-

stalled. A lter metho d can obtain information

terface for its sp ecializations. The structure can b e

ab out itself and its environment, and also ab out

reused with di erent sp ecial ho oks without changes

the calling and the called metho d. Examples are

to the template.

the name of the calling and the called metho d, the

Filters are well-suited to implement meta-

class where the lter is registered, etc. see for de-

patterns. By using a lter all activities of a pat-

tails [24]. By using these introsp ection mechanisms

tern can b e treated in one entity the lter instance

lters can exploit various criteria in order to decide

metho d. Since all messages are directed to the l-

how to handle a message.

ter the abstract tasks of the pattern can be sepa-

Often it is useful to add lters to an existing chain

rated from actual tasks of the application. But this

of lters. This can b e achieved conveniently bythe

alone would not b e a reusable solution, since for ev-

instpro c filterappend de ned for the top-level class

ery template class of every task, where the pattern

Object. Therefore this metho d is inherited by all

could b e used, a new lter metho d would havetobe

classes.

implemented. In order to achieve reusabilityweuse

Object instproc filterappend f {

a meta-class that provides the desired functionality.

[self] filter [concat [[self] info filters] $f]

This meta-class may b e stored in a library and can

}

A filterappend {Filter-2 Filter-3}

b e reused every time a similar problem o ccurs.

The steps, to obtain a reusable and instantiable

For real applications the meta-class has to be ex-

pattern based on lters from a pattern class diagram

tended with additional metho ds. In order to com-

e.g. Figure 4, are:

plete the implementation of the 1:1 meta-pattern a

metho d, which stores a reference to the sp ecial ho ok

1. Find the ho ok and template classes.

on the ob ject, has to b e de ned. Finally, the meta-

pattern is instantiated to create a ltered template

2. Create a meta-class under the general name of

class.

the pattern.

1-1-Meta-Pattern FilteredTemplate

3. Add a lter metho d to the meta-class, which

In order to provide the ho ok for the lter a sp ecial

performs all recurring tasks desired from the

ho ok class and p erhaps concretizations have to be

design pattern esp ecially the tasks of the tem-

created.

plate.

The presented scheme may b e extended for more

4. Add a constructor to the meta-class, which reg-

sp ecialized patterns, e.g. a recursive pattern mayre-

isters the lter on classes derived from the meta-

quire recursive registering of the lter. Sometimes it

class and performs pattern sp eci c initializa-

is useful but not necessary to apply a second lter

tion tasks.

e.g. in patterns with a second referencing relation-

ship, like mediator or observer in [10].

5. Add additional metho ds to the meta-class e.g.

like registration of sp ecial ho oks to avoid hard-

3.2 Design Pattern Examples

co ding of pattern semantics in the lter metho d.

The idea underlying meta-patterns splits patterns

With slight adaptations this scheme is applicable

into two parts: the template and the ho ok. Wehave

on all patterns that rely on Pree's meta-patterns

shownascheme how to apply a lter if this division

e.g. most of the patterns in [10]. But neverthe-

is p ossible. This section applies the schemeinorder

less most other patterns, since they normally involve

to implement three example patterns from [10].

messages exchanges, are supp ortable by lters. A

meta-class can be de ned as a general solution for

a large numb er of related problems. In order to use

3.2.1 The Adapter Pattern

it, the application must derive a class from it e.g.

with the name of the template class and concretize

The adapter pattern [10] converts the interface of

the application sp eci c actions that means the ho ok

a class into another interface that a client exp ects.

classes.

Therefore, an adapter is a means to let classes co op-

erate despite of incompatible interfaces. As shown

Now we show on a template for the 1:1 meta-

in Figure 5 the conventional solution is to forward

pattern, how to apply the scheme in XOTcl. The

the messages from Adapter to Adaptee by explicit

rst step is to de ne a meta-class. In XOTcl a meta-

calls. This approachentails that for every adapted

class is de ned by referencing the meta-class Class

metho d a new additional metho d must be de ned

as sup erclass of a newly de ned class:

in the adapter. This leads to an implementation

Class 1-1-Meta-Pattern -superclass Class

overhead. Moreover, the solution's program co de is

neither reusable nor traceable.

Secondly, a lter instpro c must b e de ned:

Client Target Adaptee 1-1-Meta-Pattern instproc 1-1-Filter args {

 filters actions Request SpecificRequest

 e.g. forwarding messages to the special hook }

adapter

Adapter

As the next step the constructor init registers

Request

lter on the newly created class and p erforms

the adapter->SpecificRequest()

other initialization tasks, likevariable initialization,

metho d declaration, etc.:

Figure 5: The Adapter Pattern [10]

1-1-Meta-Pattern instproc init args {

 initialization tasks

The solution for the adapter problem presented

[self] filterappend 1-1-Filter

} b elow is based on lters and avoids these problems.

It is reusable and do es not require the implementa-

verhead resulting from metho ds whicharede- tion o OtherCall adapterFilter

Client

solely for the purp ose of message forwarding.

ned Adapter

arding is handled automatically by the next

The forw request OtherCall

primitive in the lter metho d, no additional help er

Adaptee metho ds are needed.

specificRequest

By following the systematic steps presented ab ove,

weidentify the template here Adapter and the ho ok

here Adaptee. The adapter pattern resembles the

Figure 6: The Adapter Pattern Using Filters

1:1 meta-pattern of Section 3.1, but it has no sp e-

cial ho oks. The desired actions of the template are

[self] instproc setAdaptee {a} {

to forward requests to sp eci c requests. This will b e

[self] set adaptee $a

handled by the lter. Firstly,we de ne a meta-class

}

}

which replaces the pattern from the conventional de-

sign in Figure 5.

Now the abstract pattern is converted intoameta-

Class Adapter -superclass Class

class, which can be used to derive classes with the

behavior of the pattern: metho d invo cations, which

A meta-class can b e used to derive new classes that

corresp ond to registered requests, are redirected to

can access the instance metho ds of the meta-class.

the adaptee ob ject; all other invo cations are passed

The derived classes are constructed with constructor

unmo di ed to the ob ject through the next-path see

of the meta-class. Next, we de ne the lter instance

Figure 6.

metho d:

Adapter instproc adapterFilter args {

The solution in [10] su ers from the self-problem,

set r [[self] info calledproc]

since the originally called ob ject of the adapter class

[self] instvar specificRequest adaptee \

[list specificRequest$r sr]

is not the ob ject which p erforms the desired task.

if {[info exists sr]} {

This problem is not addressed by the lter solu-

return [eval $adaptee $sr $args]

}

tion presented ab ove. A more sophisticated solu-

next

tion, which do es not su er from the self-problem,

}

is to de ne the lter on the adaptee instead of the

The info calledproc command returns the origi-

adapter. For the sake of simplicitywe presented here

nally called metho d. This is the general request

the slightly simpler version.

which is to b e mapp ed to a sp eci c request. The two

A sample application of this pattern is a class

variables specificRequest and adaptee are instance

which handles network connections. Derived classes,

variables which are linked to the current scop e by

like FTP, HTTP, etc. allow one to handle sp ecialized

the primitive metho d instvar. The specificRequest

connections. All of them must implement a metho d

for the called metho d is mapp ed to the variable sr.

connect. A metho d discard of the Connection class is

adaptee is the ob ject which handles the sp eci c re-

able to close connections of all di erent kinds. Sup-

quests. If there exists a mapping of the current re-

p ose a FTP connection routine from a library class

quest, the lter forwards the message to the asso-

with a di erent interface should be used. A lter

ciated metho d. Otherwise the message is not redi-

adapter on basis of the de ned meta-class can solve

rected, but passed further on by the lter along the

this problem elegantly. Firstly the interfaces of the

next-path.

related classes:

As the next step wehave to de ne the constructor

 interface of the library class

which adds the lter to the class. In order to b e able

Class FTPLIB

FTPLIB instproc FTPLIB_connect args {...}

to set the specificRequest and adaptee variables it

is convenient to de ne instpro cs for this purp ose,

 the connection class

Class Connection

which are de ned for the derived classes. These in-

 an abstract connection method

stpro cs are created dynamically bythe constructor

Connection instproc connect args {...}

 the method to close a network connection

the init instpro c of the meta-class:

Connection instproc discard args {...}

Adapter instproc init args {

... other class definitions, like HTTP

[self] filterappend [self class]::adapterFilter

next

[self] instproc setRequest {r sr} {

Nowwe derive a class FTP from the Adapter. The

[self] set specificRequest$r $sr

meta-class's constructor de nes the twoconvenience }

metho ds and registers the lter on the new class the scattering of the pattern across several classes,

FTP automatically. Strictly sp eaking the conve- leads to a mixing of application and pattern struc-

nience metho ds are not necessary, but they provide tures that reduces reusability.

a simpler interface. The class FTP has a construc-

The pattern as presented in [10] is not an ab-

tor that automatically creates an asso ciated adaptee

stract entity; therefore, it is hard to sp ecialize and

and provides the needed information for the lter

to reuse it. Also, it is not easy to nd it in source

though the convenience metho ds.

co de, if it is not well commented, and b oth descrip-

Adapter FTP -superclass Connection

tion in the pattern classes and the runtime ob ject

FTP instproc init args {

structure are hard to introsp ect and not traceable.

FTPLIB ftpAdaptee

[self] setRequest connect FTPLIB_connect

[self] setAdaptee ftpAdaptee

In order to implementthepattern as a lter, we

}

rstly identify its elements. The comp osite class

forms the template, the comp onent class the ho ok.

Finally, the FTP class can be used and is adapted

The desired action of the template is to forward all

automatically. Since only the metho d connect was

messages to the aggregated ob jects recursively. The

a registered request, all discard-calls reach the

application sp eci c actions are the concretizations

Connection class.

that determine what these classes do with the mes-

FTP ftp1

ftp1 connect

sages. We create a meta-class:

...

Class Composite -superclass Class

ftp1 discard

Composite instproc addOperations args {...}

Composite instproc removeOperations args {...}

This simple example can be extended with only a

few more lines of co de to provide more sophisticated

As a useful enhancement to the solution in [10], new

adaptations e.g. altering parameters, adapting to

op erations are added and removed by addOperations

other ob jects, etc without architectural redesign.

and removeOperations not to b e confused with the

metho ds for aggregation handling in Figure 7. Only

registered op erations will be forwarded to the ob-

3.2.2 The Comp osite Pattern

jects in the comp osite patterns runtime structure.

All generic pattern tasks will be p erformed by a

A recursive pattern from [10] is the comp osite pat-

lter. It handles the forwarding to the comp onents

tern, shown in Figure 7. The comp osite pattern

of a comp osite:

helps to arrange ob jects in hierarchies with a unique

interface typ e, called comp onent. The ob jects are

Composite instproc compositeFilter args {

[[self] info class] instvar operations

arranged in trees with two kinds of comp onents:

set r [[self] info calledproc]

leafs and comp osites. Every comp osite can hold

if {[info exists operations$r]} {

foreach object [[self] info children] {

other comp onents.

eval [self]::$object $r $args }

Client Component }

Operation return [next]

Add } Remove

GetChild

In the comp osite lter rstly the request is com-

pared to the op erations in the operations-list. If children

Leaf Composite

the request is a registered op eration, the message Operation

Operation forall g in children

arded to the child. Though children maybe Add is forw g.Operation();

Remove

hanism functions recursively on

GetChild comp osites, this mec

the entire structure, until the leaves are reached.

In order to register the lter on a new comp osite

Figure 7: The Comp osite Pattern [10]

class automatically,we app end it in the constructor

of the meta-class:

There are several disadvantages in the implemen-

tation of the pattern in [10]. The comp osite pattern

Composite instproc init {args} {

next

structure contains dynamic ob ject aggregation, what

[self] filterappend Composite::compositeFilter

is not provided in C++. Therefore, the implementa-

}

tion lacks exible mechanisms to handle and intro-

Now we will show on an illustrative example that

sp ect the aggregation. An implementation overhead

this single metho d handles al l semantics of the pat-

results from the necessity to de ne metho ds for man-

tern. As a sample application we will build up a

agement of the dynamic aggregation. Furthermore, simple graphic:

Class Graphic To map the recursive structure of the pattern

Graphic instproc draw {} {...}

a more general solution, in which each comp osite

class gets recursively its own lter instpro c, is easily

Di erent graphics ob jects can b e de ned on basis of

achievable. This would allow one to sp ecialize the

the comp onent typ e. For example we can de ne a

lters b ehavior for certain branches of the structure

Comp osite Picture with two leaves Line and Rect-

e.g. in order to fade out parts of the picture or

angle:

to store di erent comp osites, comp onents or other

Composite Picture -superclass Graphic

classes in the pattern structure what is p ossible to

Class Line -superclass Graphic

certain degree in the solution presented. Class Rectangle -superclass Graphic

aPicture

3.2.3 The Observer Pattern bPicture aLine aRect

aLine aRect

The observer pattern presented in this section ful lls the task of informing a set of dep ending ob jects \ob-

cPicture dPicture

servers" of state changes in one or more observed

cLine

ob jects \sub jects". This problem is well known

and often addressed, e.g. by the publisher subscrib er

pattern [6] or Mo del-View-Controller [14]. Figure 9

shows the observer design pattern as presented in

[10].

Figure 8: The Comp osite Ob ject Structure observers Subject Observer

Attach wn in Figure 8 can b e con- The graphic structure sho Update Detach

Notify y: structed b for all o in observes { o->Update()

Picture aPicture }

ConcreteObserver Picture aPicture::bPicture

Line aPicture::aLine subject Update ConreteSubject Rectangle aPicture::aRect observerState

Line aPicture::bPicture::aLine GetState

SetState return subjectState Rectangle aPicture::bPicture::aRect observerState =

Picture aPicture::bPicture::cPicture subjectState subject->GetState

Picture aPicture::bPicture::dPicture

Line aPicture::bPicture::cPicture::cLine

Figure 9: The Observer Pattern [10]

An invo cation of the draw metho d on a complex ob-

ject, like:

Bosch [3] identi es the problem that the trace-

Picture addOperations draw

ability of the pattern su ers from the fact that the

metho ds attach, detach and notify do not build up

registers the draw message for all the comp onentob-

a conceptual entity and that the calls of notify must

jects in the structure. Acallofdraw draws the whole

b e inserted at every p oint where a state change o c-

hierarchy:

curs. The reusability of the concrete sub jects also

aPicture draw

su ers from these problems. A lter, which directs

all state changes of the sub ject to the observers do es

Note how simple and short it was to instantiate

not have these problems and provides a reusable so-

the sample application. Beneath the elimination of

lution.

the problems mentioned ab ove, compared to a so-

lution of the picture application following [10], the

In order to implement an observer pattern based

lter solution is much shorter and easier to under-

on lters we create meta-classes for the observer and

stand. It avoids complex structures that are con-

the sub jects. The sub jects are structured as nested

nected in manyways, and removes the need for repli-

class to preserve the unity of the pattern:

cated co de, since it takes the pattern semantics com-

Class Observer -superclass Class

pletely out of the application. Furthermore, the re-

Class Observer::Subject -superclass Class

sult is that the pattern is reusable as a program frag-

In this example we only handle the relationship b e- mentandmay b e put into a library of patterns and

tween sub ject as template and observer as ho ok not only as a design entity,which has to b e reco ded

by a lter. In a more sophisticated solution the for every usage.

second referencing relationship b etween concrete ob- Pinger::Collector instproc init args {

set hostName 132.252.180.67

server and concrete sub ject may also b e replaced by

set f [open "| /bin/ping $hostName" r]

a lter. Nowwe can de ne a lter which handles the fconfigure $f -blocking false

fileevent $f readable "[self] ping \[gets $f\]"

noti cation:

}

Observer::Subject instproc notifyFilter args {

set r [[self] info calledproc]

The op eration ping is the network event, whichmust

[self] instvar preObservers postObservers \

be handled by the collector. Since the collector is

[list preObservers$r preObs] \

[list postObservers$r postObs]

a concrete sub ject it needs a metho d getResponse

if {[info exists preObs]} {

whichisinvoked by the observers to get its current

foreach o $preObs {$o update [self] $args}

}

state:

set result [next]

if {[info exists postObs]} {

Pinger::Collector instproc ping {string} {...}

foreach o $postObs {$o update [self] $args}

Pinger::Collector instproc getResponse {} {...}

}

return $result

}

The two observers must concretize their update

metho ds. Both must catch the actual state of the

Observers are registered with the attach and detach

sub ject using getResponse and then they will up-

metho ds. As a sp ecial feature we allow b oth pre-

date their presentation. The text output presenta-

and p ost-observers to b e registered. When the lter

tion may lo ok like:

metho d is invoked, rstly all registered pre-observers

are informed, then the actual metho d is invoked and

Pinger::TextOutput instproc update {subject args} {

then all p ost-observers are informed. Finally, the

set response [$subject getResponse]

puts "PINGER: $subject --- $response"

lter returns the result of the called metho d.

}

The trivial metho ds to register or unregister ob-

For concrete applications the classes must b e instan-

servers here: attachPre, attachPost, detachPre and

tiated. Here are two collectors, some observers and

detachPost are created by the constructor init on

some attachments:

all instantiated classes, so that their ob jects can

reachthemas instproc's not presented here.

Pinger::Collector c1

Pinger::Collector c2 Pinger::Diagram d1

Observers Subjects Pinger::Diagram d2

Diagram: d1 Pinger::TextOutput t1 c1 attachPre ping d1 d2

Collector: c1

c1 attachPost ping d2 t1 c2 attachPost ping t1 d2

Diagram: d2

hes the diagrams and the text output to

Internet This attac

the collectors c1 and c2 as pre- and as p ost-observers,

Collector: c2 wn in Figure 10.

TextOutput: t1 as sho

4 Related work

Figure 10: Observer Example

We demonstrate the usage of the abstract observer

There are many other concepts with names con-

pattern by an example of a network monitor which

taining the word \ lter" e.g. in the area of mo-

observes a set of connections and maintains several

bile/distributed computing [27,16]. The comp osi-

views on these e.g. a diagram and a textual out-

tion lter mo del [1]intro duces the idea of a higher-

put. In the implementation the class Pinger encap-

level ob ject interaction mo del through abstract com-

sulates the view and collector classes, the collectors

munication typ es ACTs. Besides such basic ideas

are treated as sub jects of the observer:

of a means to change, redirect, or otherwise a ect

Class Pinger

messages, wehave not found an approach with com-

Observer::Subject Pinger::Collector

parable prop erties like lters as user-de ned meth-

Observer Pinger::Diagram

Observer Pinger::TextOutput

o ds, mixin of lter chains, inheritance, etc.. Never-

theless, in Section 4.3, we describ e other approaches

The Collector starts the observation of the network

providing language supp ort for design patterns. connection in its constructor, e.g.:

be intro duced to change the b ehavior in certain sit- 4.1 Meta-Ob ject-Proto col

uations. This wayinterpreters can b e used as a pro-

gramming device. The ineciency of the reasoning

One of the most exible environments for ob ject-

pro cess can be eliminated by techniques like par-

oriented engineering is the CLOS environmentwith

tial evaluation [8] or interpreter directed compilation

its meta-ob ject-proto col [13]. Weareconvinced that

[21].

lters can b e implemented in this environmentwhich

provides many ho oks to in uence the b ehavior and

The lter approachisanintro duction of meta-pro-

semantics of ob jects. Our lter approach di ers sig-

gramming ideas into ob ject-orientation. Even if the

ni cantly, since lters provide a high level construct,

lter never accesses the real program whicha lter

which is tailored to monitor and to mo dify ob ject in-

in XOTcl could do through the provided introsp ec-

teractions.

tion mechanisms, it has full and unlimited access

to the most imp ortant thing in ob ject-oriented run-

One example in [13] enhances CLOS with encap-

time structures: the messages. A lter handles mes-

sulated metho ds capable of restricting the access of

sages of ob jects as data which can be pro cessed in

private variables to metho ds of their class. The sys-

arbitrary ways mo di ed, redirected, handled. The

tem's metho d, used to apply metho ds, is enhanced

lters are able to reinterpret messages freely, the l-

with a sub-proto col which can add a set of function

ter metho ds are \interpreters" for messages and can

bindings to the metho d b o dy's lexical environment.

in uence all ob ject communication.

The lter would have b een a shorter and higher level

solution for this problem, b ecause it do es not require

In general the application domain of lters is very

mo di cations or additions to the underlying systems

wide. For example assertions and meta-data as pre-

b ehavior. Therefore it do es not require knowledge

sented in [24] could have b een implemented using

ab out the systems structure, likehow the system ap-

lters. The only argument against this was, that

plies metho ds or how lexical de nitions are b ound to

the implementation in C is much faster than imple-

metho ds. Moreover, the lter solution can easier b e

mentation using lters, since in the current imple-

scaled, since lters may be dynamically registered

mentation they reduce execution sp eed. However,

and unregistered.

it would be interesting to investigate, to what de-

gree compilation metho ds like these describ ed ab ove

4.2 Meta-Programming

could eliminate the overhead.

From the abstraction p oint of view lters are

4.3 Other Approaches for Supp orting

closely related to the area of meta-programming,

Design Patterns

whichwas studied in the area of lisp-like languages

e.g. [2] or in the area of logic languages, as sketched

As stated ab ove, Soukup [30] has identi ed prob-

in this section.

lems in the implementation of p opular design pat-

The lter approachis a very general mechanism

terns [10] and has shown that some patterns could

which can b e used, b esides language supp ort for de-

b e implemented as classes.

sign patterns, in various other application areas. We

The LayOM-approach [3] is the most similar to

see ob ject-orientation and lters as an analogy to the

the lter approach. It o ers an explicit represen-

interpretation layer intro duced by meta-programs

tation of design patterns using an extended ob ject-

which are used to interpret existing programs in a

oriented language. The approach is centered on mes-

new context with additional functionality [20, 21].

sage exchanges as well and puts layers around the

In [22] the abstraction intro duced bylayered inter-

ob jects which handle the incoming messages. Every

preters is called interpretational abstraction. The

layer o ers an interface for the programmer to de-

basic idea of interpretational abstraction is to treat

termine the behavior of the layer through a set of

program instructions of one program source pro-

op erators which are statically given by the layer

gram as data of another program a meta-program,

de nition. LayOM is a compiled language with a

a compiler or interpreter that reasons ab out the in-

static class concept and can b e translated into C++.

structions of the source program. During this rea-

The mo del is statically extensible with new layers.

soning pro cess new functionality can b e intro duced

The lter approach di ers from LayOM since into the source program byinterpreting the goals of

it can represent design patterns as normal classes the source program in a new context. Instead of al-

and needs no new constructs, only regular meth- tering the application program the knowledge rep-

o ds. Therefore, the lter approachis closer to the resentation, an additional interpretation layer can

5 Conclusion ob ject-oriented paradigm. Furthermore, the lters

can be dynamically recon gured added, removed,

etc. and are able to exploit introsp ection provided

The intention of this pap er is to show that ob ject-

by the underlying language.

oriented scripting languages and the management

of complexity are not contradictory and that it is

The FLO-language [7] intro duces a new comp o-

p ossible to handle complexity with a di erent set of

nent \connector" that is placed b etween interacting

advantages and tradeo s than in \systems program-

ob jects. The connectors are controlled through a set

ming languages". Scripting is based up on several

of interaction rules that are realized by op erators

principles of programming, like using dynamic typ-

not normal metho ds. This connector-approach

ing, exible glueing of preexisting comp onents, using

also concentrates on the messages of the ob jects but

comp onent frameworks etc., that can lead towards

intro duces the connectors as new entities. FLO is

a higher pro ductivity and software reuse. We have

op en for change using a meta-ob ject-proto col and

intro duced a new language construct, the lter, that

b ecause the connectors are represented as ob jects it

o ers a p owerful means for the managementofcom-

is close to the ob ject-oriented paradigm.

plex systems in a dynamic and introsp ective fashion.

It would have b een substantially more dicult to im-

The intro duced op erators are not ob ject-oriented

plement dynamic and introsp ective lters in a sys-

by nature and, therefore, less intuitive in an ob ject-

tems programming language. We b elievethatboth

oriented system than metho d invo cation. The ap-

scripting and ob ject-orientation o er extremely use-

proach of FLO involves a more complicated design,

ful concepts for a certain set of applications and that

b ecause in addition to the design patterns, connec-

our approach is a useful and natural waytocombine

tor ob jects have to b e de ned. The lter approach

them prop erly.

can avoid this problem by the automatic registration

XOTcl is available for evaluation from: of lters on the involved classes.

http://nestroy.wi-inf.uni-esse n.de /xotc l/

Both mentioned approaches do not seem to o er

the same ease as the lter in sp ecializing an abstract

pattern like in [10] to a concrete, more domain

References

sp eci c pattern in the sense of [30]. Where the

lters can simply use inheritance both approaches

[1] M. Aksit, K. Wakita, J. Bosch, L. Bergmans, A.

need the de nition of a new domain sp eci c layer or

Yonezawa: Abstracting Object Interactions Us-

connector.

ing Composition Filters, ECOOP '93, 1993.

Hedin [12] presents an approach based on an at-

[2] H. Ab elson, G.J. Sussman, J. Sussman: Struc-

tribute grammar in a sp ecial comment marking the

ture and Interpretation of Computer Programs,

pattern in the source co de. This addresses the prob-

MIT Press 1996.

lem of traceability. The comments assign roles to the

classes, which constrain them by rules like \A DEC-

[3] J. Bosch: Design Patterns as Language Con-

ORATOR must be a subclass of COMPONENT".

structs, http://bilb o.ide.hk-r.se:8080/b osch/,

The system can test automatically in the source

1996.

co de if the realized pattern satis es the given and

[4] J. Bosch: Design Patterns and Frameworks: On

derived constraint rules.

the Issue of Language Support, Workshop on

Language Supp ort for Design Pattern Frame-

This approach is not based on message exchanges

works at ECOOP'97, Jyvaskyla1997.

and is, therefore, rather simplistic, but it maybe

applied in any ob ject-oriented language. It is only

[5] D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel,

descriptive and not constructive and, therefore, not

S.E. Keene, G. Kiczales, D.A. Mo on: Common

reusable; each pattern must be commented again

Lisp Object System. In: Common Lisp the Lan-

if it is applied to new application. The ability to

guage, 2nd Edition, http://info.cs.pub.ro/onl/

assign constraints to patterns is interesting, esp e-

lisp/clm/no de260.html, 1989.

cially b ecause XOTcl provides similar abilities as

[6] F. Buschmann, R. Meunier, H. Rohnert, P. well. The assertions can constrain classes and ob-

Sommerlad, M. Stal: Pattern-oriented Software jects formally and informally. Both the consistency

Architecture { A System of Patterns,J.Wiley of the pattern class and its instances can b e checked

and Sons Ltd. 1996. at run-time.

[21] G. Neumann: A simple Transformation from [7] S. Ducasse: Message Passing Abstractions as

Prolog-written Metalevel Interpreters into Com- Elementary Bricks for Design Pattern Imple-

pilers and its Implementation, Lecture Notes mentation, Workshop on Language Supp ort

in Arti cial Intelligence 592, Springer, Berlin for Design Pattern Frameworks at ECOOP'97,

1992. Jyvaskyla 1997.

[22] G. Neumann: Interpretational Abstraction, in:

[8] A.P. Ershov: On the Essence of Compilation,in:

Computers and Mathematics with Applica-

E. Neuhold ed., IFIP Working Conference on

tions, Pergamon Press, Vol. 21, No. 8, 1991.

Formal Descriptions of Programming Concepts,

North-Holland, New York 1978.

[23] G. Neumann, S. Nusser: Wafe { An X

Toolkit Based Frontend for Application Pro-

[9] J.L. Fontain: Simple Tcl Only Object Ori-

grams in Various Programming Languages,

ented Programming, http://www.mygale.org/

USENIX Winter 1993 Technical Conference,

04/jfontain/, 1998.

San Diego, California, January 1993.

[10] E. Gamma, R. Helm, R. Johnson, J. Vlissides:

[24] G. Neumann, U.Zdun: XOTcl, an Object-

Design Patterns: Elements of Reusable Object-

Oriented Scripting Language, submitted,1998.

Oriented Software, Addison-Wesley 1994.

[25] J. Ousterhout: Tcl: An embeddable Command

[11] L. Hatton: Does OO Sync with How We Think?,

Language, Pro ceedings of the 1990 Winter

in: IEEE Software, Vol. 15 3, 1998.

USENIX Conference, 1990.

[12] G. Hedin: Language Support for Design Pat-

[26] J. Ousterhout: Scripting: Higher Level Pro-

terns using Attribute Extension, Workshop on

gramming for the 21st Century, in: IEEE Com-

Language Supp ort for Design Pattern Frame-

puter, Vol. 31, No. 3, March1998.

works at ECOOP'97, Jyvaskyla 1997.

[27] I. Piumarta: SSP Chains { from mobile objects

[13] G. Kiczales, J. des Rivieres, D.G. Bobrow: The

to mobile computing Position Paper, ECOOP

Art of the Metaobject Protocol, MIT Press 1991.

Workshop on Mobility,,Aarhus 1995.

[28] W. Pree: Design Patterns for Object-Oriented

[14] G.E. Krasner, S.T. Pop e: A Cookbook for Us-

Software Development, Addison-Wesley 1995.

ing the Model-View-Control ler User Interface

Paradigm in Smal ltalk-80, Journal of Ob ject

[29] J. Smith, D. Smith: Database Abstractions: Ag-

Oriented Programming, Vol. 1 3, pp. 26-49,

gregation and Generalization, ACM Transac-

1988.

tions on Database Systems, 2:2, June 1977.

[15] M.J. McLennan: The New [incr Tcl]: Objects,

[30] J. Soukup: Implementing Patterns, in: J.O.

Mega-Widgets, Namespaces and More, Pro ceed-

Coplien, D.C. Schmidt Eds., Pattern Lan-

ings of the Tcl/Tk Workshop '95, Toronto 1995.

guages of Program Design, Addison-Wesley

1995, pp 395-412, 1995.

[16] IONA Technologies Ltd.: The Orbix Architec-

ture, August 1993.

[31] P. Wegner: Learning the Language, in: Byte,

Vol. 14, No. 3, pp. 245-253, March 1989.

[17] H. Lieb erman: Using Prototypical Objects to

[32] D. Wetherall, C.J. Lindblad: Extending Tcl for Implement Shared Behavior in Object Oriented

Dynamic Object-Oriented Programming, Pro- Systems, Pro ceedings OOPSLA '86, 1986.

ceedings of the Tcl/Tk Workshop '95, Toronto,

[18] B. Meyer: Object-Oriented Software Construc-

July 1995.

tion - Second Edition, Prentice Hall 1997.

[33] U. Zdun: Entwicklung und Implementierung

[19] B. Meyer: Building bug-free O-O software:

von Ansatzen, wie Entwurfsmustern, Na-

An introduction to Design by Contract,

menraumen und Zusicherungen, zur Entwick-

http://ei el.com/do c/manuals/technology/

lung von komplexen Systemen in einer ob-

contract/index.html, 1998.

jektorientierten Skriptsprache, Diplomarb eit

diploma thesis, Universitat GH Essen, August

[20] G. Neumann: Meta-Programmierung und Pro-

1998.

log, Addison-Wesley 1988.