• Documents
  • Authors
  • Tables
  • Other Seers ▼
    RefSeer AckSeer CollabSeer SeerSeer
  • Log in
  • Sign up
  • MetaCart

CiteSeerX logo

Advanced Search Include Citations
Advanced Search Include Citations | Disambiguate

Confinement and representation encapsulation in Object Teams (2004)

by Stephan Herrmann
Add To MetaCart

Tools

Sorted by:
Results 1 - 2 of 2

Using Guard Predicates for Generalized Control of Aspect Instantiation and Activation

by Stephan Herrmann, Christine Hundt, Katharina Mehner, Jan Wloka - 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

by unknown authors
"... 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
The National Science Foundation
  • About CiteSeerX
  • Submit Documents
  • Privacy Policy
  • Help
  • Data
  • Source
  • Contact Us

Developed at and hosted by The College of Information Sciences and Technology

© 2007-2010 The Pennsylvania State University