The paradoxical success of aspect-oriented programming

Software entities should be open for extension, but closed to modification. Unfortunately, unanticipated requirements emerging during software evolution makes it difficult to always enforce this principle. This situation poses a dilemma that is particularly important when considering component-based systems: On the one hand, violating the open/closed principle by allowing for modification compromises independent extensibility. On the other hand, trying to enforce the open/closed principle by prohibiting modification precludes unanticipated dimensions of extension. Dynamic links increase the number of dimensions of extension that can be exploited without performing modification of existing types. Thus, dynamic links make it possible to enforce the open/closed principle in situations where it would otherwise not be possible. We present Decouplink-a library-based implementation of dynamic links for Java. We also present experience with the use of dynamic links during the evolution of a component-based control system.

show abstract

“…We have previously noted that this form of modification compromises independent extensibility. A similar criticism can be found in [20] and [25].…”

Section: Related Worksupporting

confidence: 78%

Decouplink: Dynamic Links for Java

Rytter

Jôrgensen

2011

Software Architecture

View full text Add to dashboard Cite

show abstract

“…It also has to enable modular reasoning; the customization must change the original implementation only through a public interface or well-designed extension points. Some languages such as AspectJ provide a powerful mechanism like pointcuts and thus their ability for modular reasoning is controversial [10,11]. Since they enable changes of any parts of module, preserving modularity in large scale software is not straightforward.…”

Section: Fig 2 Webpage Classmentioning

confidence: 99%

Method Shells: Avoiding Conflicts on Destructive Class Extensions by Implicit Context Switches

Takeshita

Chiba

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

We propose method shells, which is a module system for avoiding conflicts on customization by language mechanisms such as aspects in AspectJ and open classes in Ruby. These mechanisms allow programmers to customize a library without rewriting original source code but by only describing differences in a separate file. We call these mechanisms destructive class extensions. A problem with destructive class extensions is conflicts on customization. Different customizations may differently modify the same class. To address this problem, we propose a new module system named method shells. With this system, programmers can avoid conflicts since the module system automatically switches a set of customizations that has to be applied together according to the contexts declared by programmers. We present the idea of this module system and then its formal semantics. We also present an extension of Java that supports method shells.

show abstract

“…The best known skeptic -Steimann -in his OOPSLA'06 paper, argues that AOP "works against the primary purposes of the two, namely independent development and understandability of programs" and concludes that while AOP was set up to modularize crosscutting concerns, its very nature breaks modularity. Furthermore, Steimann claims that "the number of useful aspects is not only finite, but also fairly small" (Steimann 2006). Other opponents of aspect orientation, by rephrasing Dijkstra (1974), suggest that "the quality of programmers is indirectly proportional to the amount of advice they use in their programs" (Constantinides, Scotinides & Störzer 2004).…”

Section: Motivations and Goalsmentioning

confidence: 99%

“…Since an advice can plug into just about any point of execution of a program, one can never know the previous (or following) statement of any statement (Steimann 2006). An advice is even worse than GoTo as the GoTo statement transfers control flow to a visible label, while an advice does not.…”

Section: Aop Promotes Unstructured Programmingmentioning

confidence: 99%

“…The distinguishing characteristic of AO languages is that they provide quantification and obliviousness (Filman & Friedman 2001). Quantification is the idea that one can write an aspect that can affect arbitrarily many non-local places in a program (Steimann 2006). Obliviousness states that one cannot know whether the aspect code will execute by examining the body of the base code (Filman 2001).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

What Is Wrong With Aop?

Przybyłek¹

2010

Proceedings of the 5th International Conference on Software and Data Technologies

View full text Add to dashboard Cite

Modularity is a key concept that programmers wield in their struggle against the complexity of software systems. The implementation of crosscutting concerns in a traditional programming language (e.g. C, C#, Java) results in software that is difficult to maintain and reuse. Although modules have taken many forms over the years from functions and procedures to classes, no form has been capable of expressing a crosscutting concern in a modular way. The latest decomposition unit to overcome this problem is an aspect promoted by aspect-oriented programming (AOP). The aim of this paper is to review AOP within the context of software modularity.

show abstract

The paradoxical success of aspect-oriented programming

Cited by 34 publications

References 52 publications

Decouplink: Dynamic Links for Java

Decouplink: Dynamic Links for Java

Method Shells: Avoiding Conflicts on Destructive Class Extensions by Implicit Context Switches

What Is Wrong With Aop?

Contact Info

Product

Resources

About