1 / 6

AOP and Modular Reasoning [ICSE05]

Explore first principles of modularity and modular reasoning, analyzing how AOP complements OOP and impacts system interfaces. Learn about crosscutting concepts and effective modular design practices.

mskelley
Télécharger la présentation

AOP and Modular Reasoning [ICSE05]

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AOP and Modular Reasoning [ICSE05] • Start with first-principles definition of modularity and modular reasoning • localization, interfaces, enforcement, composition • Provide example and analysis showing that: • in the presence of ccc, OOP is not modular • in the presence of ccc, AOP is modular • But… • interfaces depend on system configuration • AOP makes that explicit • explains more about what crosscutting means ______ [ICSE05] Kiczales and Mezini. Kiczales and Mezini - FOAL 2005

  2. Crosscutting Structure and Interfaces • Aspect cuts interface • through Point and Line • What crosscutting means • The gestalt of AOP class Line { private Point p1, p2; Point getP1() { return p1; } Point getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; } } aspect UpdateSignaling { private Display Shape.display; publicvoid Shape.setDisplay(Display d) { this.display = d; } pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int) || execution(void Shape+.set*(*))); after(Shape s) returning: change(s) { Display.update(s); } } class Point { privateint x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; } void setY(int y) { this.y = y; } } Kiczales and Mezini - FOAL 2005

  3. Parts Kiczales and Mezini - FOAL 2005

  4. m Composed parts • composition determines • both interfaces and component structure Kiczales and Mezini - FOAL 2005

  5. Crosscutting Structure and Interfaces • Parts stay the same • Interfaces are extended • Declarative • What “details” means can change class Line { private Point p1, p2; Point getP1() { return p1; } Point getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; } } aspect UpdateSignaling { private Display Shape.display; publicvoid Shape.setDisplay(Display d) { this.display = d; } pointcut change(Shape shape): this(shape) && (execution(void Shape.moveBy(int, int) || execution(void Shape+.set*(*))); after(Shape s) returning: change(s) { Display.update(s); } } class Point { privateint x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; } void setY(int y) { this.y = y; } } Kiczales and Mezini - FOAL 2005

  6. Why paper matters to us • What theory of AOP should say • interface depends on configuration • “aspect control” systems can account for that • expand “modular” to encompass AOP • that has been the idea for 10 years • Stop focusing on advice and simple pointcuts! • inter-type declarations • more interesting pointcuts (i.e. dflow, pcflow…) • the fun is in saying “there is a well-definable crosscutting interface there,I’m going to define it and program against it” • a chance to play with all that fancy semantics (AOP as a strategic technology) Kiczales and Mezini - FOAL 2005

More Related