1. Aspect-Oriented Programming using Phoenix Marc Eaddy MSR Intern Columbia University

2. Motivation Limitations of traditional OO –inheritance –aggregation Some concerns not separated well concerns I don’t know about yet coupling issues with multiple clients “operational” requirements AOP = Open Classes + Advice –Promise of greater separation of concerns –Satisfies specific business needs of the Phoenix team

3. Open Classes Ability to split a class definition into separate modules Similar to Partial Classes in C# except –post-compile time –works on assemblies; no source req’d –can extend a class at any time –language agnostic DEMO: Adding foreach-style syntactic sugar DEMO: Adding Visitor pattern

4. Advice Ability to inject code at specific points in a program Examples: –profiling –logging/tracing –log call sites for a particular function –log field get/set –dirty bit (persistence/synchronization) –caching –error checking/handling –DEMO: enforce field invariants (non-null, const, data flow)