Classes as Layers: Rewriting Design Patterns with COP Alternative Implementations of Decorator, Observer, and Visitor
Matthias Springer‡ Hidehiko Masuhara‡ Robert Hirschfeld†,§ ‡ Department of Mathematical and Computing Sciences, Tokyo Institute of Technology, Japan † Hasso Plattner Institute, University of Potsdam, Germany § Communications Design Group (CDG), SAP Labs, USA; Viewpoints Research Institute, USA [email protected] [email protected] [email protected]
Abstract this paper and present the alternative implementations of the This paper analyzes and presents alternative implementations three design pattern using that mechanism. For every design of three well-known Gang of Four design patterns: Decora- pattern, we present an example, identify shortcomings in a tor, Observer, and Visitor. These implementations are more conventional implementation, show a COP-based implemen- than mere refactorings and take advantage of a variant of tation, and discuss consequences and possible disadvantages context-oriented programming that unifies classes and layers of our solution. to overcome shortcomings in a conventional, object-oriented implementation. 2. Mechanism and Notation Keywords Design Patterns, Decorator, Observer, Visitor, For the implementation of the design patterns that we show Context-oriented Programming, Layers in Section 3, a number of features and mechanisms are re- quired that are not typically found in COP frameworks. We 1. Introduction evaluated some of these features separately in our previous work but not together in this combination. The code list- Software design patterns are reusable blueprints for prob- ings shown in the remainder of this paper are written in an lems that occur frequently in software design. Among them imaginary dynamically-typed, class-based, object-oriented are the most prominent ones by “Gang of Four” [2]. We se- programming language with Java-like syntax. lected three of their design patterns (Decorator, Observer, and Visitor), identified shortcomings in a conventional object- Partial Methods In layer-based context-oriented program- oriented implementation, and present an alternative imple- ming [4], layers can refine methods of other classes. Such mentation using layer-based context-oriented programming refinements are called partial methods. When a layer is ac- (COP). These new COP implementations are not merely tive, the method lookup first looks for a corresponding partial refactorings of their OO counterparts; Decorator and Ob- method in that layer, before falling back to the original im- server differ in their semantics and solve functional inade- plmentation. Multiple layers can be active at the same time, quacies, in addition to making the source code in our opinion forming a layer composition stack. more understandable by reducing object interaction. The new implementations are based on a new concep- Classes as Layers This work builds on top of ideas from tual idea for organizing partial methods. In most COP frame- our previous work which unified layers and classes [7]. We works, partial methods belong to a layer. In our system, there assume that there is no dedicated layer construct. Instead, is no dedicated layer construct and partial methods belong classes and their instances can act as layers. In addition to to classes, allowing arbitrary objects to affect other objects member methods and static methods, classes can provide by intercepting (layering) their methods. The following sec- member partial methods and static partial methods. A partial tions will give an overview of the COP mechanism used in method can refine existing methods or add new methods to the target class.
Permission to make digital or hard copies of all or part of this work for personal or Since layers are implemented by objects, arbitrary (layer) classroom use is granted without fee provided that copies are not made or distributed objects can be activated/deactivated. We use the term layer for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the object to denote an object that acts as a layer in a certain author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, situation and affected object to denote the object whose or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. behavior is adapted. As long as a layer object is active (see COP’16, July 17-22 2016, Rome, Italy paragraph Layer Activation), its partial methods are in effect. Copyright is held by the owner/author(s). Publication rights licensed to ACM. If the layer object is a class, its static partial methods are ACM 978-1-4503-4440-1/16/07...$15.00. http://dx.doi.org/10.1145/2951965.2951968 in effect. If the layer object is a non-class object, its class’s this.b; // -> B.b member partial methods are in effect. this.c; // -> B.c thisLayer Accommodating State Layer objects can refine existing .a; // thisLayer undefined and add new methods to affected objects (via partial meth- /* ... */ ods), but they cannot add additional instance variables. There } are three reasons for this decision: First, it is unclear how } conflicts should be handled, i.e., what if two layer objects de- If the affected object or layer object is a class, then this or fine an instance variable with the same name. Second, adding thisLayer references static methods and fields. Otherwise, new instance variables is difficult from an implementation it references member fields. point of view, because they would have to be stored separate from the other instance variables. Third, such functionality is Layer Object Activation We assume that layer objects can not required for the examples in this paper. Instead, a layer be activated globally, in a block scope, and for a certain object’s class can define its own instance variables that can affected object. In the first case, a layer object is activated by be accessed inside partial methods. If there is a one-to-one calling its activate method and remains active in the entire mapping between a layer object and an affected object, this program until it is deactivated explicitly. In the second case, is as if the instance variable belonged to the affected object. a layer object is activated using with statements taking the Partial methods effectively belong to the target class, i.e., layer object as an argument and followed by a block, within a class different from the layer class. Method calls and which the layer object remains active. In the third case, a instance variable references inside a partial method are by layer object is activated only for a single affected object by default resolved in the target class, but we assume that the calling the affected object’s activate method with the layer thisLayer keyword can be used to access instance variables object as an argument, and the layer object remains active of the layer class. until it is deactivated explicitly. This is contrary to the first • Keyword thisObject1: Lookup in the affected object two cases, where more than one object might be affected (all instances of classes for which a partial method is defined). • Keyword thisLayer: Lookup in the layer object
• Keyword this: Try lookup in affected object, then layer def affectedObject = new A(); object def layer = new B(); • No keyword given: same as this // global activation The following listing shows the this and thisLayer in layer.activate(); a simple example with a member method foo and a member layer.deactivate(); partial method bar. class A{ // target class // block scope activation def a; with (layer) { /* active in here */ } def b; without (layer) { /* inactive in here */ } } // per-object activation class B{ // layer class affectedObject.activate(layer) def b; affectedObject.deactivate(layer) def c; There must be a mechanism in place to determine the def A.bar() { // partial method for A.bar precedence of these three activation mechanisms. For exam- this.a; // -> A.a ple, if a layer object is activated globally and then deactivated this.b; // -> A.b for a single affected object, that deactivation should have this.c; // -> B.c precedence over the previous layer object activation. The de- thisLayer.a; // -> error tails do not matter in this work; previous work has proposed thisLayer.b; // -> B.b various mechanisms [6]. thisLayer.c; // -> B.c } 3. Design Patterns
def foo() { This section presents three well-known design patterns [2]: this.a; // -> error Decorator, Visitor, and Observer. For every pattern, there is an example implementation using the COP mechanism 1 Not used in this paper, only mentioned for the sake of completeness. described in Section 2. 3.1 Decorator This example is hard to implement with a conventional The Decorator design pattern is used to add responsibilities to Decorator, because the decorated object is referenced by its an object at run-time. A Decorator is typically implemented four neighboring fields. Whenever a field is wrapped with as a wrapper object holding a reference to the original object. a Decorator, these references would have to be replaced by Multiple Decorators can be applied by wrapping the object the decorated object. An alternative implementation could multiple times. use object composition with a set of Decorator items (one One disadvantage of a wrapper implementation is that re- of them being fire) for every field instead of a Decorator: sponsibilities cannot be added or removed dynamically with- Every field would act as a container for items and references out loss of object identity. After wrapping a Decorator around would always point to fields instead of field wrappers. Field an object, the resulting wrapped object has an object identity methods would delegate to item methods internally. different from the original object (object schizophrenia [5]). Consequences A COP Decorator implementation can dif- If that wrapped object should be used everywhere the original fer from a conventional object-oriented implementation in a object is in use, it has to be replaced one by one. way that might not be anticipated by the programmer: Dec- orator methods are not only visible from the outside (when COP Implementation A Decorator is a layer object with calling a method on the decorated object), but also from in- partial methods for modified or additional behavior and is side. This can be a problem if a method should behave dif- activated only for the decorated (affected) object. A partial ferently in both cases. For example, a scroll bar Decorator method can issue a proceed call to combine the new behav- might add the proportions of the scroll bar to the values re- ior with the original one. As soon as a Decorator object is turned by methods width and height, even if text rendering activated, it is active wherever the (original) decorated object (implemented in the text box) depends on the original imple- is used, solving the problem of object identity. In cases where mentation. a Decorator adds state to a decorated object, there should be One limitation of a COP implementation of the Decorator exactly one decorated object per Decorator object, with the design pattern is that the Decorator is always specific to a additional state as instance variables of the Decorator object class, because COP relies on static types for the target class (many-to-one relationship between layer objects and affected in the partial method signature even in dynamically-typed lan- object). guages. For example, the Decorator in the example can deco- Example Figure 1 shows the data structure for a computer rate only Field objects but not other objects with the same game that is based on 2D grid representation. The game method. The partial method could, however, target methods consists of a matrix of game fields. Every game field has of an interface (or superclass) instead of a concrete class in references to its neighboring fields and methods for draw- statically-typed languages (e.g., the superclass Object). ing the field and for handling incoming entities. For exam- 3.2 Visitor ple, the player entity might enter the game field from a neighboring field. Game fields can be decorated with the The Visitor design pattern is used to modularly add new op- BurningFieldDecorator, representing a field that is on fire erations to a set of classes, typically forming a tree structure, and causes damage to entering entities. This Decorator also without having to modify these classes. Every class has an modifies the draw method to show a fire animation. accept method taking a Visitor as an argument and calling a type-specific method on the Visitor in a double-dispatch Field BurningFieldDecorator fashion. The Visitor design pattern allows programmers to -left : Field -damage separate the base functionality of a set of classes from addi- -right : Field +Field.draw() -top : Field +Field.enter(entity) tional concerns that are only needed in certain situations and -bottom : Field encapsulated in the Visitor class. +draw() +enter(entity) One disadvantage of a double-dispatch implementation is def Field.enter(entity) { entity.health -= thisLayer.damage; complex object interaction. Applying an operation provided proceed(entity); by a Visitor to an object of unknown type requires calling an } accept method on the object with the Visitor as an argument, which will then call the type-specific visit method. Figure 1: Example: Decorator Methods as Partial Methods COP Implementation A Visitor is a layer object with par- tial visit methods for all classes in the object structure. A field field can be set on fire by creating a decorator These methods do not refine existing base methods but are for it and applying it, as shown in the following listing. new methods. Within a visit method, it is possible to call def decorator = new BurningFieldDecorator(); the visit methods of associated objects directly and without decorator.damage = 15; double dispatch. Note, that visit methods can be renamed, field.activate(decorator); making it possible to use multiple visitors at the same time, as long as there are no name clashes between visitor methods. Expr listing shows how an abstract Visitor can be implemented with COP.
abstract class ExpressionVisitor def PlusExpr.visit() { NumberExpr PlusExpr MultiplyExpr left.visit(); -value -left -left -right -right right.visit(); } (a) Classes for Arithmetic Expressions
/* ... /* OperationCounterVisitor -countPlus } def PlusExpr.visit() { -countMultiply thisLayer.countPlus++; +NumberExpr.visit() left.visit(); class OperationCounterVisitor extends ←- +PlusExpr.visit() right.visit(); +MultiplyExpr.visit() ExpressionVisitor { } def PlusExpr.visit() { (b) Operations Counter Visitor thisLayer.countPlus++; super.visit(); Figure 2: Example: Visitor Methods as Partial Methods }
/ ... / A Visitor can maintain internal state as instance variables of * * } the Visitor object. In contrast to a conventional Visitor im- plementation, a COP-based Visitor is reduced to a container The interesting part of this example is the super call: for partial methods and maybe internal state (i.e., the Visi- Should this statement invoke the visit method in the su- tor disappears and becomes part of the affected objects). In perclass of PlusExpr or the partial visit method in the particular, there is no accept method anymore. superclass of OperationCounterVisitor? In our previous Example Figure 2(a) shows the class diagram for the tree work, we proposed the concept of an effective superclass hier- node classes in an arithmetic expressions library. The library archy [7], i.e., a mechanism that formalizes the semantics of supports numeric literals, plus operations, and multiplica- super calls. According to that mechanism, every class C in tion operations. Figure 2(b) shows the layer-based operation the superclass hierarchy is prepended with one (partial) class counter Visitor, which counts how often plus operations and per active layer L, containing partial methods defined in L for that class C. Consequently, the super call in the example multiplication operations appear in an expression. To that 2 end, the layer object has two integer variables for counting would call the partial method in ExpressionVisitor . these operations. 3.3 Observer Before the Visitor can be used, it must be activated, for example using block-scoped layer activation. The Visitor can The Observer design pattern is used to deliver changes in the then be invoked by calling the visit method on the expres- state of a subject to an observer. A subject typically maintains sion object. Inside a visit method, another subexpression a list of observers and notifies them via their update method can be visited by invoking its visit method without double whenever its state changes. Information about the changed dispatch. state is either directly passed as an argument to the update method or queried by the observer. def visitor = new OperationCounterVisitor(); One shortcoming of this implementation is that there with (visitor) { are no levels of notification. For example, some observers expression.visit(); might only be interested in a certain kind of events, while } others want to be notified about all state changes. However, a println(visitor.countPlus + ", " + ←- conventional implementation of the Observer design pattern visitor.countMultiply); does not let multiple observers specify when they should be 3 Note that per-object activation on expression is not notified . sufficient, because the Visitor would then not be active for COP Implementation An observer is a layer object with subexpressions. partial methods for the methods that trigger state changes. Consequences In a traditional Visitor implementation, li- 2 In the absence of other active layer objects, a super call in that partial braries often provide abstract Visitor classes with visit method would try to lookup visit in Expression (starting with partial methods containing the object traversal code. A concrete Vis- methods provided by layers), i.e. there is no proceed statement but the itor would then overwrite visit methods with visiting code semantics of super is extended. and a super call to visit associated objects. The following 3 The related Publish-subscribe pattern [1] does support this feature. Such a partial method calls proceed and then triggers the Consequences The example presented in the previous para- change reaction code in the observer. The collection of ob- graph uses per-instance activation to observe a specific object. servers and the code broadcasting change notifications to Global activation allows an observer to observe all instances observers disappears and is hidden in the method lookup of a class. For example, the login monitor could observe all mechanism and proceed calls. user managers in a system if it is activated globally. The partial methods of an observer should be confined to Example Figure 3 shows the class diagram for a user man- the public methods of the subject, as they would otherwise ager component. The user manager acts as the subject and rely on internal implementation details and violate encapsu- supports checking credentials, creating new user accounts, lation. Moreover, in comparison to a conventional implemen- and changing permissions for a given user. Two observers, tation, a COP-based implementation provides less flexibility a login monitor and a security log are defined. The login as to when a change notification should be triggered. It is not monitor is a live view for user activity and shows the num- possible to insert those notifications at an arbitrary point in- ber of successful and failed login attempts in a bar chart. side a method, because an observer can only listen to method The security log records more severe events such as account call events. This limitation, in turn, might prevent entangle- creation or changing user permissions, but not successful or ment of object responsibilities and change notifications. failed login attempts. The crucial point in this example is that different events are relevant for the login monitor and Object-oriented Implementation Notification levels can be the security log, which cannot be adequately handled in a implemented without context-oriented programming using conventional Observer implementation with only a single no- only object-oriented programming by providing multiple tification mechanism. Observer interfaces. For every level, the subject maintains a separate list of observers and notifies only these observers LoginMonitor <