110 likes | 119 Views
This text discusses the concept of branches in aspect-oriented software development, comparing them to procedures and methods. It explores the flexibility of programming languages in specifying "when to do it" and the benefits of separating behavioral concerns. The design goals of extensibility, refactorability, and parameterizability are also highlighted. Examples of AOP languages and approaches are provided.
E N D
Aspect-Oriented Software Development Karl Lieberherr
Karl Lieberherr: From Doug Orleans’ PhD work Idea of branches • Each branch: • what to do • when to do it • Compare to a procedure • only says: what to do when a procedure with specific name is called. • a branch has control over when it will be called while a procedure has minimal control over when it is called
Karl Lieberherr: From Doug Orleans’ PhD work Idea of branches • Each branch: • what to do • when to do it • Compare to a method • only says: what to do when a method with specific name is called and the receiver has the right type. • a branch has control over when it will be called while a method has minimal control over when it is called
better separation of concerns may lead to less efficient compilation? Requirement on programming language • The degree of flexibility that the programming language allows in specifying the “when to do it” determines how well behavioral concerns can be separated. • By allowing a more precise specification of the “when to do it” part of a branch, we remove the tangling that would otherwise occur if the dispatch had to be implemented explicitly.
But • “when to do it” is very flexible: can do dangerous things? • Can influence an existing program in a way that is not desirable?
Design goals • Extensibility: It should be easy to add new functionality without editing code. • Refactorability: It should be easy to tease out existing functionality into something reusable: avoid duplication. • Parameterizability: It should be easy to reuse functionality in different contexts • Minimize duplication and tangling
Design goals • What is most important: reducing tangling. • If an incremental change is done through modification of existing code, it likely leads to tangling of concerns. • And crosscutting concerns lead to tangling too. • Is reducing code duplication a subcase of reducing tangling?
What is crosscutting? • One-to-many forward relationships and many-to-one inverse relationships. many-to-one inverse one-to-many forward
Key idea of AOP • allow a module to define its trigger events so that one does not need to edit a large number of classes in order to program a crosscutting concern.
Modules • “what to do” • group several things to do together • what-module • “when to do it” • express several conditions together • when-module
what advice visitor visitor method b. branch body collaboration method managers method body procedure body when pointcut strategy, cg visitor method s. branch condition adapter exclusion sets method signature procedure name Module examples • AspectJ • DJ • DJ • BOP • AC • COOL • OOP • Proc.Prog.