Programming languages typically support a xed set of composition operators, with xed semantics. This may impose limits on software designers, in case a desired operator or semantics are not supported by a language, resulting in suboptimal quality characteristics of the designed software system. We demonstrate this using the well-known State design pattern, and propose the use of a composition infrastructure that allows the designer to de ne custom, composable composition operators. We demonstrate how this approach improves several quality factors of the State design pattern, such as reusability and modularity, while taking a reasonable amount of e ort to de ne the necessary pattern-related code.
However, we have observed that in each programming language only a few of the known composition operators are at the developer's disposal as language features. This hinders the modularity of source code. Thus, the ability to modularize source code is limited by the choice of composition operators made by the language designers. In our research, we want to enable the developer to freely use and mix all existing|and future|composition operators.
For most of the composition operators, di erent variations
exist, e.g., when inheriting from a class, either the parent
(e.g., in Beta) or the child implementation (e.g., in Java)
may have precedence. While approaches exist to support
di erent variants of single operators simultaneously (e.g.,
Beta-style and Java-style inheritance in [
To avoid this limitation, often domain-speci c languages (DSL) are developed that provide composition operators tailored toward a speci c program domain. However, developing a DSL only pays o , when it is used su ciently often.
If this approach, thus, is not feasible and a general-purpose
language is used, often the missing composition operators
are emulated by a speci c programming style, e.g., in terms
of design patterns [
To emulate composition operators, design patterns typically require some pieces of code which are application-independent (possibly tailored with element names from the application program) but cannot be localized in one module; we refer to these code pieces as boilerplate code. Boilerplate code entails several disadvantages.
Firstly, it obfuscates the design; instead of specifying the relation of two or more modules explicitly, this code de nes their composition imperatively. Because this code is scattered over multiple participating modules, the design intention becomes even more implicit.
Secondly, boilerplate code is di cult to write. While it is not very sophisticated, its correctness is not easily enforced; for example, consider the Visitor pattern, where each Element class must implement the method void accept(Visitor visitor){ visitor.accept (this); }1. Each class contains the same line, but it is not possible to factor it out into the superclass. 1In languages like Java with an overloading semantics for methods, the static type of the argument distinguishes between the accept methods for di erent Element types in a
Visitor.
Finally, while it is sometimes necessary to combine
multiple composition operators, not all required
operators can be emulated by design patterns. As an
example, consider the expression problem [
As also others have noticed [
In our research, we are concerned with developing a composition infrastructure, where the developer can choose from di erent composition operators and from di erent variations thereof. However, we do not simply aim at providing a
xed set of composition operators to choose from; but we aim to provide an infrastructure in which composition operators can be user-de ned. In addition, our approach allows to re-use and combine implementations of composition operators|thereby developing new composition operators| because they are rst-class. This also makes our approach open for future developments in the research of composition operators.
In this paper we present our approach through the example of the State pattern and our prototypical Co-op language. We have chosen this pattern because it is suitable to demonstrate the interplay between di erent composition operators, namely forwarding and delegation semantics as well as aspect-oriented composition. By this example we show that customizable composition operators can lead to a re-usable implementation of design patterns as well as to improved modularity of source code.
First, the State pattern has to be instantiated and tailored to
this speci c application. In general, many patterns
(including the State pattern) specify roles that have to be mapped
to implementation-speci c classes. However, parts of these
classes represent common pattern-de ned behavior, made
speci c for a particular instantiation of the pattern. This
obfuscates the generality of the design pattern, decreases the
As an alternative, the State pattern therefore also explicitly
suggests that all state transitions can be kept in a single
2. COMPOSITION ISSUES DEMONSTRATED location, e.g., a transition table. This addresses the
scatterIn this section, we demonstrate the occurrence of issues ing of transition statements over the program, thus making
caused by language limitations, based on a concrete exam- it easier to, e.g., check whether an instantiation of the State
ple. For this purpose, we discuss the object-oriented \State" pattern matches a corresponding state diagram, or to modify
design pattern [
In this alternative design, the constructor of TCPInterface constructs a table of state transitions. The methods in class TCPInterface each call the method changeState(..).
This method is parameterized by the action that is being executed, which is needed to look up the \next" state in the transition table. Similar to the code that \manually" forwards method calls to the current state object, the invocation of method changeState, passing the action, is thus replicated for each action supported by the state machine implementation.
state separation between application-speci c and pattern-generic code, and makes it harder to reuse common parts of the pattern implementation (\boilerplate" code).
Speci cally in this example, the most important occurrence
of boilerplate code is found in the methods de ned in class
TCPInterface. For each action (e.g., openPort,
receiveSyn, etc.) supported by the state machine, this interface
class has to de ne a method that forwards calls to the
currently active state. As shown in gure 1, the forwarding
method has to pass the this reference to the state object,
such that it can, e.g., call changeState on the context
object. Similarly, whenever a new action has to be added
to the state machine, additional boilerplate code has to be
added to both the State superclass TCPState, as well as
TCPInterface. Both issues can be addressed more
concisely in languages that support explicit delegation [
Second, pattern implementations may impose limitations on the way a particular concept is expressed. In the case of the State pattern implementation as shown in gure 1, the behavior associated with each state is modularized. However, state transitions are encoded as part of the actions, and thus become scattered over multiple State implementation classes. One way to improve on the situation described above, is by addressing limitations in the underlying implementation language. In this case speci cally, both implementations can bene t from a language that supports explicit delegation, whereas the table-based design can additionally bene t from a language that supports pointcut-advice constructs.
We demonstrate this in detail in the next section; it should be noted, however, that this example is meant as a demonstrator for the usefulness of more exible composition operator support in general, even if space limitations prevent us from discussing other examples here. 3. USING COMPOSABLE COMPOSITION
OPERATORS
Our approach is based on a composition infrastructure, which
supports composition primitives that allow programmers to
design custom or domain-speci c composition operators. This
infrastructure is implemented as an object-based language
called Co-op, which is discussed in detail elsewhere [
Figure 3 shows a schematical overview of a Co-op-based design of the State pattern, applied to the TCP/IP example.
As is the case with the original OO pattern, it supports both design alternatives discussed in the previous section (i.e., encoding transitions as part of the state implementations, or as a separate transition table). The lower half of the diagram contains the reusable, pattern-generic parts, which should ful ll two main tasks. First, it establishes and controls a delegation relation between a context object (as it is called in the original pattern description; in our example, class TCPInterface ful lls the role of context ) and state implementation objects (instances of TCPClosed, TCPListen, etc.). Second, in case a table-based implementation is desired, it automatically ensures that the speci ed state transitions are executed at the appropriate moment, i.e., without adding any invocations to the application-speci c state implementations (in the upper half of the diagram).
Below, we discuss each module described in the diagram in some detail, and show how this approach reduces the amount of boiler-plate code in the application-speci c part.
Listing 1 shows the implementation of the generic, reusable parts of the State pattern. An instance of the State pattern can be created by constructing an instance of module
TCPInterface @portNumber @stateObjects @fsm init(portNumber) getPortNumber() getStateObject(stateName) getFSM()
<<Delegation>> <<creates>>
<<creates>>
StatePattern @target @currState @currDelegator init(target, initState) addTransition() getCurrentState() getDelegatorOperator() changeDelegatorOperator(newState)
TCPClosed openPort() StatePattern. To facilitate the delegation from the context object to an object representing the current state, each state pattern instance keeps references to the context and currentState objects, and a reference to the delegation operator2. These instance variables of the pattern are de
ned on line 2. The constructor (lines 4{8) calls the operation that establishes the delegation relation (line 7). This operation, changeDelegatorOperator(..) (lines 10{ 18), which should be invoked whenever a state change is required, deactivates the delegation to the current state object (lines 12{13), and activates a new delegation relation from the context object to the new state object (lines 16{17).
We lack the space to discuss the internal details of the
Delegation operator in detail, but a discussion of this exact
operator can be found in prior work [
Finally, lines 20{22 implement the state transition
mechanism used in the table-based pattern implementation: by
invoking addTransition, a pointcut-advice instance is
constructed, which triggers after the speci ed action is
invoked on the fromState. Whenever the pointcut triggers,
as an advice the operation stateChangeImpl is invoked,
as de ned on lines 33{35, which changes the state to the
selected toState. The module StateTransition stores
references to the pattern instance, as well as the desired
toState, so that these can be used by the advice3.
2In Co-op, operators are themselves implemented as
modules, and can be referenced as rst-class objects. For a
detailed explanation, see [
First, by using delegation, it is no longer necessary to write manual forwarding operations in the context class (here: TCPInterface). Second, when using a table-based implementation, the pointcut-advice composition operator removes the need to manually invoke a method that decides about the next state. Note that although our approach allows the use of such a transition table, this is by no means obligatory; embedding transitions in action implementations works ne, as well. However, when transition tables are used, our approach removes the need for boilerplate associated with the original implementation.
Listing 2 shows how the State pattern implementation de
ned above as a custom, \pluggable" composition operator that can be used in any Co-op program, is applied to the
TCP/IP example discussed in section 2. 1 module TCPInterface { 2 var portNumber, fsm; 3 4 5 6 init:aPortNumber { var closedState, listenState, synReceivedState,
establishedState; } stateChangeImpl { patternInstance changeDelegatorOperator: toState; 35 } 36 } 37 // etc. for other TCP states not shown here ing the module StateTransition super uous, but our much simpli ed implementation of AspectJ-like pointcutadvice does not support this at present. 1 module Main { 2 main { var tcpserver; 3 tcpserver = TCPInterface new: "80"; 4 tcpserver openPort; // Request port open
Listing 2: Application of the generic State-pattern implementation In this listing, the constructor of module TCPInterface, found on lines 4{21, sets up the state machine: it creates an instance of each TCP state modeled in this example (lines 8{11), and initializes a State pattern instance (line 14), appointing itself as the context object, and setting closedState as the initial state object. In this example, we also used the pointcut-advice based transition mechanism, which is initialized in lines 16{19. Note that all the initialization code here is completely application-speci c, and also, no boilerplate related to the internal \machinery" required by the pattern implementation is visible. Once the state machine is thus set up, the delegation and pointcut-advice operators automatically take care of e ectuating the desired state machine behavior.
The remaining code in listing 2 shows the mock-up state implementations. Note that the state modules do not contain or need any references to the state pattern. Still, because of delegation, you can still use behavior of class TCPInterface by means of this-calls, such as this getPortNumber (line 27).
An example demonstrating how the complete state machine can be instantiated and executed is shown in listing 3. Note that in listing 3, no boilerplate code or references to the state pattern are necessary either. 5 6 7 } } tcpserver receiveSyn; // Receive incoming conn.
//etc.
Listing 3: Using the state machine implementation When the state machine is initialized (line 5), calls will be delegated to the initial state, an instance of TCPClosed.
Thus, when openPort is invoked (line 6), the call is delegated to the operation openPort in TCPClosed, as shown before. After this action has been executed, the pointcutadvice that executes the state transition to listenState, an instance of TCPListen, is automatically invoked, since it triggers after the invocation of openPort on the instance of TCPClosed. Thus the state machine implementation automatically delegates calls to the appropriate implementation, and automatically triggers state changes.
The complete example as well as a prototype Co-op-interpreter
(a plain jar- le, no installation required) can be downloaded
from the Co-op website [
To the best of our knowledge, there are no other languages
that o er dedicated support for user-de ned composition
operators (that can be reused and combined), at least not
within the domain of object-oriented and aspect-oriented
languages. Please note that this excludes languages that
offer generic extension mechanisms|such as macros in Lisp|
or allow for the extension and modi cation of the program
through metaprogramming; our work is particularly related
to metaprogramming [
This means that the di culty of language design|except for the concrete syntax|is now on the MOP designer. Indeed, our work might just as well have been presented as a novel design of a MOP, but for practical reasons we chose to use a concrete language, Co-op. We are not aware of any MOPs (or languages, or frameworks) that o er similar generic abstractions and structure as we presented in this paper. In particular, we do not know any MOPs that provide abstractions for de ning new composition operators with similar variety, expressiveness and composability. For example, Coop explicitly supports a variety of object-oriented as well as aspect-oriented composition operators.
Of the research that aims at providing frameworks for
higherlevel languages through re ection or meta object protocols,
we just mention COLA [
We have used the example of a modular, reusable implementation of a design pattern to exemplify that a single xed composition technique is insu cient, while at the same time demonstrating that a design pattern implementation can in fact be modeled as a composition operator that `extends' the language.
In [
Rajan and Sullivan [
They base their evaluation of the EOS language on a
comparison with the AspectJ implementations of patterns in
[
Several e orts have been made to represent design patterns
as rst-class entities. For example, in [
These roles are called participants in [
Hanneman and Kiczales [
Although this paper shows only one example, the results
can be generalized. As has been discussed by the example
of the Visitor pattern in section 1, or by the example of other
patterns in [
In addition, our approach of using a composable composition infrastructure (called Co-op) allows the de nition of new composition operators that reuse existing ones. We have shown this by expressing the State design pattern as a custom composition operator, which reuses two existing operators that implement explicit delegation and a basic pointcutadvice mechanism. Also as a result of this, we could de ne such a relatively complex and reusable operator in less than 50 lines of code.