Gustaf Neumann and Uwe Z dun Information Systerns and Software Techniques University of Essen, Germany {gustaf.neumann,uwe.zdun} @uni-essen.de Abstract t objects need access to module internals, is another challenging problem [14]. The necessity to let a module Object-oriented software system composition is tradi- address the requirements of several clients, while stay- tionally centered on class-based designs. In this paper ing focused enough for each specific client, entails the we will take a look onto design issues from an object- need for a new model of abstraction. Such a model are level point of view and discuss the idea to build designs open implementations [15], for instances implemented especially tailored for the object-level. Currently the with meta-object protocols [16]. object-oriented paradigm is still evolving. New ideas, Reflective techniques, like read/write introspection, in like design patterns, enhance composability on the class- conjunction with dynamics of object and class-system, level. Based on the example of three design patterns are a solution to allow modules to adapt their descriptive from [11] (Decorator, Strategy, and Observer) we will representation to client requirements. A general prob- show in this paper how to refine class-level designs at lem is, how to accessthese features properly. Approach- the object-level. es, like [16] or [22], use a distinction between a meta-level We believe that the underlying concepts of a program- and a base-level, where the behavior of the base-leve! is ming paradigm and the capabilities of the programming controlled through meta-objects. This is a useful but language should be of comparable expressiveness. Re- low-level approach. The per-object mixins used in this garding the class-level implementation of design pattero- paper provide a higher-level interface to let objects be s, we have introduced a language construct called fil- adapted for client requirements and theyare rompletely ter , providing a powerfullanguage support for class-level transparent for client objects. patterns. Similarly, in order to implement the object- Moreover, they avoid the distinction between meta- level patteros presented in this paper, we use another level and base-level. We consider the implied splitting of language construct, tailored for the implementation on the tasks of one design entity into t wo (or more) objects, the object-Ievel, called per-object mixins. This construct a base-level and a meta-level object, as the biggest dis- is implemented in the scripting language XOTCL, which advantage of meta-object protocols. We rather propose is an extension of MIT's OTCL. the usage of meta-classes (see [19]) or per-object mixins in order to be able to decompose base- and meta-part, while preserving the one design entity as one object of 1 Introduction the implementation. Another common problem to object-orientation is Ohject-orientation is hased on the principles of infor- that numerous components, with several classes and al- mation hiding and ahstraction through encapsulation 1 their relationships, have to work in concert. The e- and on specialization through inheritance. This ap- volving complexity of applications makes it difficult for proach has proven weIl in reducing complexity of soft- software engineers to make the right design decisions. ware architectures, hut unfortunately it still entails cer- Therefore, it is important to make good designs acces- tain obstacles and limitations. Currently a central weak- sible to other software engineers and this way reusable. ness is the composition of ohjects. Class-levellanguage The object-oriented design rommunity proposes design constructs are ahle to describe the properties and the he- patterns [11] as a solution to this problem. havior of their instances in detail, hut they suffer from Design patterns are a description of situations in powerful means to express how classes and ohjects are which several classes cooperate on a certain task [26]. composed and how they are inter-related. They typically can be found in the "hot spots" [25] of The discrepancy hetween the aim of ahstractions hid- software architectures. Design patterns are rollected in ing their implementation and the reality, where clien- catalogs, like [11, 9]. Most efforts in the literature con- centrate on cataloging of patterns. By using design pat- introduce a language construct called per-object mixin teros, they become a part of the programmer's paradigm (investigated as a language construct in [20]). [2]. Moreover, we will show that the general idea of refin- Unfortunately, in order to reuse the design experience ing class-level constructs to the object-level is not limit- represeoted in the design pattem in an implementation, ed to programming language constructs. Large program the programmer has to recode the pattem for every us- structures, like class-Ievel design pattern, can also be age. Therefore, the design pattem is no entity of the transformed into an object-specific pattern. In this pa- programming language. In [3] more problems with de- per we will show such a refinement on the example of sign pattem implementation are investigated, i.e. ; the decorator, strategy and observer pattern [11]. We will use the new language construct per-object mixin to .Traceability: The pattem is scattered over the ob- implement the object-specific patterns properly. Before- jects and, therefore, hard to locate and to trace in hand, we give a brief overview of the XOTCL language, an implementation [26]. We also see the problem of in which we have implemented the per-object mixins. traceability of ron-time structures, induced by the absence of introspection mechanisms in languages like C++. 2 Extended OTCL .Sel/-Problem: The implementation of several pat- terns requires forwarding of messages,e.g. an object Extended OTcL (XOTcL, pronounced exotickle) is an A receives a message and forwards it to an object extension of OTcL [28] which is an object-oriented fiavor B. Once the messageis forwarded, references to sel/ of the scripting language TcL (Tool Command Language refer to the delegated object B, rather than to the [23]). Generally, there is a fast and high qualit y devel- original receiver A [17]. oproent of software systeros in scripting languages, like TcL. Since theyoffer a dynamic type system with auto- .Reusability: The implementation of the pattem matic conversion, they become easily extensible through must be recoded for every use. coroponents (e.g. written in X6TcL, TcL, or C). All coroponents use the same string interface for argumen- Implementation Overhead: The pattem implemen- t passing and therefore they automatically fit together . tation requires several methods with only trivial be- The coroponents can be reused in unpredicted situations havior, e.g. methods solely defined for messagefor- without change. In [24] and [19] it is pointed out that the warding. evolving component frameworks provide a high degree of code reuse, and offer easy usage and rapid application Some approaches, like [2, 3, 10, 12] provide a language deve!oproent. support for design patterns to solve this problem. In [25] seven meta-patterns are identified that define most of OTcL preserves and extends these important features the patteros of Gamma et.al. [11]. In [19] we have shown of TcL. It offers object-orientation with encapsulation an approach, how to generally language support patterns of data and operations, single and multiple inheritance, based on these meta-patterns, using a new class-level a three leve! class system based on meta-classes, method language construct, called filter . chaining and rich read/write introspection facilities, al- lowing the programmer to change all relationships dy- Filters are instance methods registered for a class C . namically (see [28] for detalls). Every time an object of dass C receives a message, the In XOTcL every object is associated with a class over filter is invoked automatically. When the filter is reg- the class relationship. Classes are ordered by the rela- istered, all messagesto objects of this class (and all its tionship superclass in a directed acYclic graph. Classes sub-classes) must pass the filter, before they reach their are a special objects with the purpose of managing other destination object. Therefore, the filter is a very power- objects. "Managing" means that a class provides meth- fullanguage construct. In rombination with its rich in- ods to create and destroy instances, and that it provides trospection facilities and the dynamics of filter registra- a repository of methods for its instances ("instprocs") tion it is able to achieve a powerfullanguage support for to defioe their behavior. Thrthermore, a classes can be design patterns, but also has strong meta-programming combined through single or multiple inheritance. The abilities and can be used as a general tracing facility. instance methods common to all objects are defioed in Hut this power comes with a certain coarseness,when the roat class Object (predefioed or user defioed). Since applied to the object-Ievel. Generally it is possible to a class is a special (managing) kind of object it is man- specialize a filter enough to satisfy every client object's aged itself by a special class called "roeta-class" (which requirements. Hut we think the more intuitive way is, to manages itself). One interesting aspect of meta-classes provide a language ronstruct, similar to the filter espe- is that by providing a constructor, pre-configured class- cially tailored for the object-Ievel. For this task we will es can be derived. New user-defined meta-classes can 2 be derived from the predetined meta-class Class in or- As a consequence, the per-object mixins extend the der to restrict or enhance the abilities of the classesthat method chaining of a single object. they manage. All inter-object and inter-class relation- An arbitrary class can be registered as a per-object ships are fully dynamic and can be changed at arbitrary mixin for an object by the predefined mixin method.