To model and implement the evolution of behavior, we propose the context relation as an extension to the existing object-oriented model. Several design patterns were presented to demonstrate the use of the relation for facilitating evolution, evolving either the behavior of a single object or the behavior of collaborating objects.
As discussed, the context relation is meaningful at both the design and implementation levels. It may also impact software testing. As inheritance and dynamic binding modified traditional program flow and subsequent testing models, the context relation may as well. If a base class is well tested, and a context class is added to alter its methods, how much retesting is required? Harrold, McGregor and Fitzpatrick present a hierarchical incremental testing (HIT) technique for reusing base class tests with derived classes [7]. The algorithm can be customized for testing the context relation.
Software engineering principles have long supported a black-box or strongly encapsulated form of programming, with a strict boundary formed around a software component, namely its interface. This is founded on the principle that hiding implementation details will facilitate evolution by reducing the impact of change. Such encapsulation is advocated in object-oriented programming by providing a boundary around a class, with access control mechanisms. It has been widely acknowledged that inheritance breaks encapsulation, and it is clear that the context relation may do so in the same manner as inheritance. If a derived class is allowed to access members inherited from a base class, changes in the base class may require maintenance of the derived class as well. The same maintenance relation exists between a base class and its context classes. As C++ tries to manage the maintenance effort by providing access control, the same may apply to the context relation.
It is clear that the shortcomings of the static class construct, namely that there is one implementation of an interface per object, often require elaborate work-arounds as demonstrated with the strategy pattern. The work-arounds themselves usually violate encapsulation, for example the Strategy class must be made a friend of the Receiver class. While a static class definition may be considered the encapsulation boundary, it can be argued that a more extended view of the class should be the boundary, namely the base class along with its contexts, representing the dynamic class definition.
An implementation of the visitor pattern using context attachment to calls has been developed in Java and STKLOS by Doug Orleans at Northeastern University.
Acknowledgments. We thank Walter Hürsch, Doug Orleans and Salil Pradhan for fruitful discussions. We also thank Mitch Wand for detailed comments on this paper.
This work has been partially supported by the National Science Foundation under grant numbers CDA-9015692 (Research Instrumentation) and CCR-9402486 (Software Engineering).
This work has been partially sponsored by the Defense Advanced Research Projects Agency, and Rome Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-96-2-0239. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon.
The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency, Rome Laboratory or the U.S. Government.