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.