Aspect oriented programming in Ruby: talk given on 14/04/2014 at LRUG (London Ruby User Group). http://camillebaldock.co.uk/aspect-oriented-programming-in-ruby Many of us developers love arguing about architecture that we dislike and refactoring our code to loosen coupling and weaken dependencies between our objects. Unfortunately, some overarching parts of our applications, like persistence, networking, notifications, logging, auditing, are scattered in our code, forcing us to specific explicit dependencies between them and our domain objects. Aspect-oriented programming is a solution to the problem of some features affecting virtually all business requirements, and expresses that problem in a compact and DRY way. In this practical talk, I: - introduce the basic concepts of AOP, and how it is still relevant even in a non-statically typed language like Ruby - show you how to easily and quickly leverage some AOP principles in your Rails application - play with some AOP-friendly constructs in Ruby 2, in particular TracePoint walk you through two existing Ruby frameworks to practice Aspect-Oriented Programming I even attempted to prove that not all things coming from the Java world are necessarily bad. Website: http://camillebaldock.co.uk Twitter: @camille_

1. ASPECT-ORIENTED
PROGRAMMING IN RUBY
Camille Baldock
!
@camille_, http://camillebaldock.co.uk

2. WHAT IS AOP?

3. FROM JAVATO RUBY

4. FROM JAVATO RUBY

5. FROM JAVATO RUBY

6. WHY USE AOP ?
Tangled code Scattered code
A modularity approach for logical concerns that cut across the
domain model.

7. SOME REQUIREMENTS DON’T
MAP NICELY IN OO

8. CROSS-CUTTING CONCERNS
• Logging (tracking program behaviour)
• Verification (checking program behaviour)
• Policy enforcement (correcting behaviour)
• Security management (preventing attacks)
• Profiling (exploring where a program spends its time)

9. JOIN POINT
Join points are the individual points of interest within a
program’s execution which the aspect is advising.

10. ADVICE
Advice is code executed before, after, or around a given join
point.

11. TYPES OF ADVICE
Before
!
After returning
!
After raising
!
After (… returning or raising)
!
Around

12. POINTCUT
A point cut is a set of join points. It represents the total set of
criteria necessary for execution of a given piece of advice code.

13. ASPECT
An aspect is a collection of point cuts and their respective
advice, collected to address a specific concern.

18. SINGLE RESPONSIBILITY
CHECK
• One responsibility
• We still have two dependencies:
• Repository object which provides persistence to our snippets.
• Logger which helps us track activity.

24. THE RAILS APPROACH
class Snippet < ActiveRecord::Base
…
end

25. BUT WHAT IF WANTTO USE
POROS ?

26. –DHH
“A standardised AOP framework has never really
taken off in Ruby because the language itself already
supports most of the desirable functionality of AOP.”

28. METAPROGRAMMING - A
SUBSTITUTE FOR AOP ?
• Metaprogramming can at most be the vehicle for
implementing AOP.
• AOP enforces the semantics which are supposed to
be solved by metaprogramming.

29. –Gregor Kiczales, creator of AOP
“Another advantage of a direct semantics for AOP is
that it helps with abstraction.When we look at a
complex object model, it's simpler to think of it as
describing the behaviour of the objects, rather than
describing transformations on method tables that
implement the behaviour of objects.The same is true
of AOP—it's simpler to think in terms of aspects
of an object's behaviour, rather than
transformations on classes, which transform
method tables, which implement the behaviour of
objects.”

30. METAPROGRAMMING:TOO
MUCH POWER ?
~175 uses of alias_method in Rails

31. METAPROGRAMMING:TOO
MUCH POWER ?
base.class_eval do
alias_method :render_without_layout, :render
alias_method :render, :render_with_layout
end

32. DOESN’T DEPENDENCY
INJECTION ALREADY SOLVETHIS ?
• Both achieve a loosely coupled architecture.
• Both achieve a better separation of concerns.
• Both offload some concerns from the base code.

33. DOESN’T DEPENDENCY
INJECTION ALREADY SOLVETHIS ?
• DI is good when you have a dependency on a
component, you just don’t know to which
implementation.

34. DOESN’T DEPENDENCY
INJECTION ALREADY SOLVETHIS ?
• AOP is good when you need to apply a common
behaviour to a large number of elements of code.
The target code is not necessarily dependent on
this behaviour to be applied.

35. TO BE “AOP”,YOU NEED…
• Interception: Interjection of advice, at least around
methods.
• Introduction: Enhancing with new (orthogonal!) state and
behaviour.
• Inspection:Access to meta-information that may be
exploited by point cuts or advice.
• Modularisation: Encapsulate as aspects.

36. DIY
• alias
• define_method
• adding a method to an instance

37. ABOUT METHOD_MISSING
• Used everywhere in Rails and other toolkits.
• Your method_missing often collides with mine…
• Consider using aspects to preserve modularity and
reduce collisions.
• Reduce the actual calls to method_missing.

39. AQUARIUM

40. AQUARIUM

41. RUBY PURISTS, LOOK AWAY!

42. RUBY ADVISING JAVA, JAVA
ADVISING RUBY
• Aquarium can run on JRuby
• Ruby aspects can advise Java
• Java aspects can advise Ruby code

43. ASPECTOR

44. WHAT CROSS-CUTTING
CONCERNS ?
• Persistence
• Logging
• Verification
• Policy enforcement
• Security management

45. TRACEPOINT
• To be considered for profiling, analysing method
usage and your call stack
• Ruby 2.0

46. THANKS!
Stephen Best (@thebestie)
Notes, references, slides and further reading on:
http://camillebaldock.co.uk/aspect-oriented-
programming-in-ruby

47. Q&A