Results 1 -
2 of
2
Using Guard Predicates for Generalized Control of Aspect Instantiation and Activation
- In Dynamic Aspects Workshop (DAW’05), at AOSD 2005
, 2005
"... Many aspect-oriented programming languages employ static transformations in order to produce the executable system. Some aspects, however, should only be effective if certain conditions are fulfilled that can only be evaluated at runtime. The naïve approach of using conditionals within the advice co ..."
Abstract
-
Cited by 4 (3 self)
- Add to MetaCart
Many aspect-oriented programming languages employ static transformations in order to produce the executable system. Some aspects, however, should only be effective if certain conditions are fulfilled that can only be evaluated at runtime. The naïve approach of using conditionals within the advice code easily leads to scattering and tangling regarding these conditionals, suggesting that they should be separated from the advice code. In this paper we analyze how aspects can be made conditional, i.e. how their effect can be controlled based on runtime values. We present an extension to the ObjectTeams/Java programming language that provides a flexible means for controlling the instantiation and activation of an aspect implemented by a ”team ” and its roles by means of guard predicates. We discuss different points in a program for which we consider a guard predicate suitable. We argue that this approach is more general than the ways other aspect languages control aspect instantiation and activation. Our approach makes use of the fact that in Object Teams aspects are implemented as first-class objects, which have full support for inheritance and polymorphism. 1.
Gradual Encapsulation
"... Strictly enforced encapsulation is a key concept for modular software designs. However, in many situations like unanticipated reuse, productivity can be raised by a more flexible approach to encapsulation. Also the discussion about the role of “obliviousness ” in aspect-oriented programming is one i ..."
Abstract
- Add to MetaCart
Strictly enforced encapsulation is a key concept for modular software designs. However, in many situations like unanticipated reuse, productivity can be raised by a more flexible approach to encapsulation. Also the discussion about the role of “obliviousness ” in aspect-oriented programming is one instance of a general conflict between strictness and flexibility. Here, different technologies take different stands and the choice of a particular technology locks a project into prioritizing one side over the other. In this paper we suggest that this choice should not be determined by technology but technology should support the co-existence of encapsulation and its inverse — decapsulation — within a single system. We postulate four principles that define a solution space, called “gradual encapsulation”, in which each project should find the best fitting balance between encapsulation and decapsulation with the option to shift this balance during the life time of a system. We use the programming language ObjectTeams/Java for illustrating how encapsulation and decapsulation can be supported by technology and how the four principles can be implemented on top of such technology. 1

