14
1 Aspects and Modularity: The Hope and the Challenge Jonathan Aldrich Institute for Software Research International School of Computer Science Carnegie Mellon University

Aspects and Modularity: The Hope and the Challenge

  • Upload
    jaunie

  • View
    21

  • Download
    0

Embed Size (px)

DESCRIPTION

Aspects and Modularity: The Hope and the Challenge. Jonathan Aldrich Institute for Software Research International School of Computer Science Carnegie Mellon University. Why Modularity?. Protect client code from changes to design decisions encapsulated within a module [Parnas, others] - PowerPoint PPT Presentation

Citation preview

Page 1: Aspects and Modularity: The Hope and the Challenge

1

Aspects and Modularity:The Hope and the Challenge

Jonathan Aldrich

Institute for Software Research InternationalSchool of Computer ScienceCarnegie Mellon University

Page 2: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 2

Why Modularity?

• Protect client code from changes to design decisions encapsulated within a module• [Parnas, others]

• Protect invariants of module code from ill-behaved clients• [Milner, others]

Page 3: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 3

Aspects: A New Hope

Key benefit: capture concerns more locally and consistently

• Better protects clients from change by localizing crosscutting concerns

• Can be used to consistently enforce invariants of a module

Page 4: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 4

Aspects: A Double-Edged Light-Saber?

• This works when you use AOP to modularize a concern

• What happens when the client of a module uses AOP?

Page 5: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 5

Aspects: The Phantom Menace

• Aspect-oriented clients can become dependent on details of a module’s implementation

• Aspect-oriented clients can break a module’s invariants

Page 6: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 6

Non-Solution: Read-Only Aspects

• AOP clients may still depend on information that might change

• Even non-mutator AOP clients can break invariants• Untrusted code can view sensitive data• Aspects can create new objects with

broken invariants

• Many concerns require mutator aspects

Page 7: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 7

Non-Solution: Semantic Pointcuts

• Control flow, data flow pointcuts are more robust• Still can be broken if control/data flow

does not exactly match problem

• Only one kind of semantic pointcut is a solution:

Do what I mean!We say this already with interfaces!

Page 8: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 8

Non-Solution: Semantic Pointcuts

• Control flow, data flow pointcuts are more robust• Still can be broken if control/data flow

does not exactly match problem

• Only one kind of semantic pointcut is a solution:

Do what I mean!We say this already with interfaces!

Page 9: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 9

Non-Solution: Semantic Pointcuts

• Control flow, data flow pointcuts are more robust• Still can be broken if control/data flow

does not exactly match problem

• Only one kind of semantic pointcut is a solution:

Do what I mean!We say this already with interfaces!

Page 10: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 10

Solution: Interfaces• Use Interfaces to Mediate Interaction

• Aspects may advise entry/exit join points of a module• Aspects may advise pointcuts explicitly exported by a

module• “do what I mean” by this pointcut

• Other advice is prohibited

• Module changes which preserve interface pointcuts also preserve client behavior• Can be formalized and proved for simple pointcuts

• Aldrich, FOAL ‘04, ECOOP ’05• Work needed to extend to practical system

• Interfaces also enforce internal invariants

This story is old…but controversial in AOP!

Page 11: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 11

Solution: Interfaces• Use Interfaces to Mediate Interaction

• Aspects may advise entry/exit join points of a module• Aspects may advise pointcuts explicitly exported by a

module• “do what I mean” by this pointcut

• Other advice is prohibited

• Module changes which preserve interface pointcuts also preserve client behavior• Can be formalized and proved for simple pointcuts

• Aldrich, FOAL ‘04, ECOOP ’05• Work needed to extend to practical system

• Interfaces also enforce internal invariants

This story is old…but controversial in AOP!

Page 12: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 12

Obliviousness is Bunk!

• Well-known AOP “requirement”• Code does not have to be specifically prepared to

receive AOP enhancements

• Bunk because aspects depend on details of code

• As soon as you advise it, code is no longer oblivious!• Can’t change code or rely on invariants obliviously

(without knowing about aspects)

Page 13: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 13

Obliviousness is Bunk!

• A proxy for what you really want: agility• Ease of change of crosscutting concerns

• Modify a pointcut declaratively and locally within a module

• After-the-fact enhancement

Tools could give it to you transparentlyView or modify a pointcut in an interface

Even if it’s a reflection of a more global pointcutAdd or modify a pointcut that cuts across interfaces

This may require negotiation with another stakeholder (other developers, the user, the application architect)

Page 14: Aspects and Modularity: The Hope and the Challenge

April 20, 2023 14

Obliviousness is Bunk!

• A proxy for what you really want: agility• Ease of change of crosscutting concerns

• Modify a pointcut declaratively and locally within a module

• After-the-fact enhancement

• Maybe tools could give this to you transparently• View or modify a pointcut in an interface

• Even if it’s a reflection of a more global pointcut• Add or modify a pointcut that cuts across interfaces

• This may require negotiation with another stakeholder (other developers, the user, the application architect)

• Insufficient to calculate one from the other• Both must be editable if you want both modularity and

agility• Changes to pointcuts in interfaces of module require

negotiation