Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Aspect oriented programming in Ruby


Published on

Aspect oriented programming in Ruby: talk given on 14/04/2014 at LRUG (London Ruby User Group).

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.

Twitter: @camille_

Published in: Software, Technology, Education
  • Be the first to comment

Aspect oriented programming in Ruby

  1. 1. ASPECT-ORIENTED PROGRAMMING IN RUBY Camille Baldock ! @camille_,
  2. 2. WHAT IS AOP?
  6. 6. WHY USE AOP ? Tangled code Scattered code A modularity approach for logical concerns that cut across the domain model.
  8. 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. 9. JOIN POINT Join points are the individual points of interest within a program’s execution which the aspect is advising.
  10. 10. ADVICE Advice is code executed before, after, or around a given join point.
  11. 11. TYPES OF ADVICE Before ! After returning ! After raising ! After (… returning or raising) ! Around
  12. 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. 13. ASPECT An aspect is a collection of point cuts and their respective advice, collected to address a specific concern.
  14. 14. SINGLE RESPONSIBILITY CHECK • One responsibility • We still have two dependencies: • Repository object which provides persistence to our snippets. • Logger which helps us track activity.
  15. 15. THE RAILS APPROACH class Snippet < ActiveRecord::Base … end
  17. 17. –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.”
  18. 18. 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.
  19. 19. –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.”
  20. 20. METAPROGRAMMING:TOO MUCH POWER ? ~175 uses of alias_method in Rails
  21. 21. METAPROGRAMMING:TOO MUCH POWER ? base.class_eval do alias_method :render_without_layout, :render alias_method :render, :render_with_layout end
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. DIY • alias • define_method • adding a method to an instance
  27. 27. 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.
  28. 28. AQUARIUM
  29. 29. AQUARIUM
  31. 31. RUBY ADVISING JAVA, JAVA ADVISING RUBY • Aquarium can run on JRuby • Ruby aspects can advise Java • Java aspects can advise Ruby code
  32. 32. ASPECTOR
  33. 33. WHAT CROSS-CUTTING CONCERNS ? • Persistence • Logging • Verification • Policy enforcement • Security management
  34. 34. TRACEPOINT • To be considered for profiling, analysing method usage and your call stack • Ruby 2.0
  35. 35. THANKS! Stephen Best (@thebestie) Notes, references, slides and further reading on: programming-in-ruby
  36. 36. Q&A