HOW TO DEAL WITH ENCAPSULATION IN ASPECT-ORIENTATION Lodewijk M.J. Bergmans (lbergmans@acm.org) Mehmet Aksit (aksit@cs.utwente.nl) http://trese.cs.utwente.nl TRESE GROUP – UNIVERSITY OF TWENTE, P.O. BOX 217, 7500 AE, ENSCHEDE, THE NETHERLANDS Abstract—Encapsulation has received considerable interest in the context of object-oriented pro- gramming. In particular the encapsulation of objects that are composed through inheritance has been discussed repeatedly [Snyder 86, Micallef 88]. Aspect-oriented composition has similar considerations. However, most approaches to aspect-orientation or multi-dimensional composi- tion of concerns do not enforce encapsulation of the implementation details of concerns. This might even lead to the impression that aspect-orientation conflicts with encapsulation. We claim that aspect-orientation and encapsulation are orthogonal, and that it is possible, and desirable, to enforce strong encapsulation in the presence of aspects. We illustrate this by giving an exam- ple and showing a (proposed) solution based on the composition filters model. 1. INTRODUCTION & PROBLEM STATEMENT A general concern in the encapsulation discussion is that re- vealing implementation details to clients and/or re-users of a module is bad, in particular from a maintainability perspec- tive. We claim that encapsulation is (even more) desirable in the case of crosscutting specifications. Consider the follow- ing example: Assume that in a corporate environment, a set of objects is communicating with each other within a distributed hetero- geneous system. Here, heterogeneity means that objects may be implemented in different languages and/or running on ma- chines with different operation systems or hardware. In such environments, it is generally agreed that revealing internal details to clients is a bad thing, because this makes clients vulnerable to changes in the implementation. In gen- eral, by using approaches like COM and CORBA, the im- plementation details and even the implementation language and platform can be hidden. An Interface Definition Lan- guage (IDL) is used to describe the externally visible inter- face in a language-independent manner. Now assume that due to changes in the business require- ments, some of the objects in the system have to be extended with a simple security mechanism. When a secure object re- ceives a message, it verifies whether the sender object is in its access-list or not. If the sender object is not it the list, the message is rejected. Here, security is a crosscutting aspect since it has to be implemented in multiple objects. These ob- jects may be instances of different classes, but not all in- stances of a class may require security. Although aspect-oriented languages simplify the task of im- plementing crosscutting concerns, additional complexities may arise. Consider the example: ! The implementers of the application might not have been aware of the desired security extension. This means the existing modules in the system could not have been pre- pared for such an extension. ! The application will likely be in continuous evolution. This means that the implementation of the modules may be changed or new modules may be introduced. If the se- curity concern depends on the implementation details of the modules, changing the implementation of modules may require changes to the implementation of the secu- rity concern. Since in the future the security concern may also evolve, and/or new crosscutting concerns may be in- troduced, having dependencies between the crosscutting concerns and implementation of modules considerably increase the complexity of the system. ! In the corporate system example, the software modules may be implemented in different programming lan- guages. The designers of the crosscutting concern, which is security in this case, have to consider the heterogeneity of the environment. 2. REQUIREMENTS To avoid the problems introduced in the previous section, we think that the following two basic requirements must be ful- filled: ! implementation encapsulation: Aspect specifications must only refer to interfaces. The implementation of ob- jects may change for all kinds of reasons and therefore