Evolution of object behavior using context relations

Abstract

A collection of design patterns was described by Gamma, Helm, Johnson, and Vlissides in 1994. Recognizing that designs change, each pattern ensures that a certain system aspect can vary over time such as the operations that can be applied to an object or the algorithm of a method. The patterns are described by constructs such as the inheritance and reference relations, attempting to emulate more dynamic relationships. As a result, the design patterns demonstrate how awkward it is to program natural concepts of behavioral evolution when using a traditional object-oriented language.In this paper we present a new relation between classes: the context relation. It directly supports behavioral evolution, and it is meaningful at the analysis, design, and implementation level. At the design level we picture a context relation as a new form of arrow between classes. At the implementation level we use a small extension of C++. The basic idea is that if class C is context-related to a base class B, then B-objects can get their functionality dynamically altered by C-objects. Our language construct for doing this is a generalization of the method update in Abadi and Cardelli's imperative object calculus. A C-object may be explicitly attached to a B-object, or it may be implicitly attached to a group of B-objects for the duration of a method invocation. We demonstrate how the context relation can be used to easily model and program the Adapter, Bridge, Chain of Responsibility, Decorator, Iterator, Observer, State, Strategy, and Visitor patterns.

Generation of visitor components that implement program transformations

“…Research on the use of visitors in this capacity is sparse. Seiter, Palsberg, and Leiberherr suggest similar uses to illustrate that the visitor pattern is difficult to use for analyses that require a lot of context [19]. While we agree with their assessment in general, we believe that visitor-based solutions in existing programming languages are sufficient for many analysis problems that arise in software-engineering environments.…”

“…Despite our success in analyzing formal specifications, we found that to implement more sophisticated program analyses requires the management of a significant amount of analysis context by the visitor. Unfortunately, visitors that must manage a large amount of context can be very difficult to design and to understand [19].…”

Self-configuring object-to-relational mapping queries

“…The pattern fixes the traversal order of the visited structures; a typical analysis needs to consider information located in multiple locations instead of cleanly hierarchical structures. This kind of analysis of multiple fragments is awkward with the visitor pattern [10]. Refinements for applying the visitor pattern include a system of multiple curried visitors, among other things [11].…”

Plug-and-play composition of features and feature interactions with statechart diagrams

“…Other approaches are Mixins [5], composition filters [1], aspect-oriented programming [7,14] and [6]. One of the main ingredients for feature-oriented programming, adapting to a context, can also be found in [21]. These approaches do however not cover graphic design methods.…”