Reusable Object-Oriented Components

Yannis Smaragdakis

University of Texas at Austin

TAY 2.124, Austin, TX 78712

Tel: (512)471-9711, fax: (512)471-7866

Most often, a reusable object-oriented component cannot be a single object (or class, at the source level). The reason is that objects may have complicated interactions with other objects and cannot be reused independently. This is not a new observation; it has, for instance, been explored in object-oriented application frameworks (or just frameworks). Frameworks, however, can only provide a skeleton for actual applications--not an entire implementation. Also, there is no clear way to compose frameworks so that one can refine or extend the other. Ideally we would like to have a collection of components describing a domain, such that composing them in various ways yields entire concrete applications.

The requirements for reusable object-oriented components can be satisfied by using a programming pattern known as a "mixin layer". Mixin layers are immediately available by combining parameterization (templates) and inheritance in a specific C++ idiom.

The complexity of software has driven both researchers and practitioners toward design methodologies that decompose design problems into intellectually manageable pieces and that assemble partial products into complete software artifacts. The principle of separating logically distinct and (largely independent) facets of an application is behind many good software design practices. A key objective in designing reusable software modules is to encapsulate within each module a single (and largely orthogonal) aspect of application design. Many design methods in the object-oriented world build on this principle of design modularity (e.g., design patterns and collaboration-based designs). The central issue is to provide implementation (i.e., programming language) support for expressing modular designs concisely.

My work addresses this problem in the context of collaboration-based (or role-based) designs. Such designs decompose an object-oriented application into a set of classes and a set of collaborations. Each application class encapsulates several roles, where each role embodies a separate aspect of the class's behavior. A cooperating suite of roles is called a collaboration. Collaborations express distinct (and largely independent) aspects of an application. This property makes collaborations an interesting way to express software designs in a modular way.

While collaboration-based designs cleanly capture different aspects of application behavior, their implementations often do not preserve this modularity. Application frameworks are a standard implementation technique. As shown by VanHilst and Notkin [VN96a], frameworks not only do not preserve the design structure but also may result in inefficient implementations, requiring excessive use of dynamic binding. VanHilst and Notkin proposed an alternative technique using mixin classes in C++. Their approach mapped design-level entities (roles) directly into implementation components (mixin classes). It suffered, however, from highly complex parameterizations in the presence of multiple classes, and the inability to contain intra-collaboration design changes. This caused them to question its scalability, and seek a way to explicitly capture collaborations as distinct implementation entities.

I explore an alternative way to implement multiple-class components. My work showed how to remove the difficulties of the VanHilst and Notkin method (see [VN96a-c]) by scaling the concept of a mixin to multiple classes. These scaled entities are called mixin layers [SB98a-b]. A mixin layer can be viewed as a mixin class encapsulating other mixins with the restriction that the parameter (superclass) of an outer mixin must determine all parameters of inner mixins. Employing mixin layers yields significantly simpler code and shorter compositions than in the VanHilst and Notkin model. The primary means of expressing mixin layers is C++ templatized nested classes, but the same ideas are applicable to CLOS or Java with mixins. In general, I study mixin layers from a programming language standpoint. Some of the issues involved have to do with interface (constraint language) support for multiple-class components, verifying the consistency of a composition of layers, and handling the propagation of type information from a subclass to a superclass.
 

To give the reader a taste of the mixin layers technique, the general form of a mixin layer in C++ is:

That is, a C++ mixin layer is a class template, whose template parameter becomes its superclass upon instantiation (this pattern is called a mixin).  Additionally, the mixin layer contains nested classes such that instantiating the layer determines their superclasses. This idiom can be used to express components that are composable in an exponential number of ways. Inheritance is employed at two levels: a mixin layer inherits nested classes from its superclass and nested classes inherit members (methods and variables) from the nested classes of the layer's superclass. Reference [SB98a] shows how mixin layers are applicable to the implementation of separate graph algorithms with compositions like:

typedef DFT < REGION < DEFAULTW < UGRAPH CycleC;

and

to yield many different applications where the components remain the same but only their composition changes. An up-to-date memo containing practical C++ implementation advice can be found in my web page.