after_do is a simple gem, that helps you fight cross-cutting concerns with an approach similar to Aspect Oriented Programming (AOP). after_do allows you to execute blocks (callbacks) after/before specific methods of a class or a module are called.
If the class extends
AfterDo you can simply do this by
MyClass.after :some_method do whatever_you_want end # you can also do before MyClass.before :a_method do so_much end
Some facts about after_do:
- no runtime dependencies
- small code base: code is around 160 lines of code with blank lines, comments and everything - simplecov reports less than 80 relevant lines of code
- simple DSL
- no monkey patching
Why would you want to do this?
Well to fight cross-cutting concerns. These are concerns in an applications that apply to multiple objects (e.g. they cross-cut). A popular example is logging - you might want to log multiple actions of different classes but logging is not the primary concern of the class in question. With logging you litter all your code with logging statements - that concern is spread over many files and adds unnecessary noise to them. With after_do you could put all the logging in one file. Other use cases include gathering business statistics or redrawing timing of elements. This should generally not be done to alter behavior of the class and its instances - this makes programs more confusing rather than easier to understand.
The idea for this is inspired by Aspect Oriented Programming - e.g. do something when specific methods are executed. However I doubt that this formally fulfills the lingo (join points, aspects, advice...)
Add this line to your application's Gemfile:
And then execute:
Or install it yourself as:
$ gem install after_do
And then you have to require the gem before you can use it:
In order to use after_do the class/module you want to use it with first has to extend the
AfterDo module. You can do this right in the class definition or afterwards like this:
With this setup you can add a callback to
method like this:
MyClass.after :method do magic end
With after_do you can do simple things like printing something out every time a method is called as in this example:
class Dog def bark puts 'Woooof' end end Dog.extend AfterDo Dog.after :bark do puts 'I just heard a dog bark!' end dog = Dog.new dog2 = Dog.new dog.bark dog2.bark # Output is: # Woooof # I just heard a dog bark! # Woooof # I just heard a dog bark!
Getting a hold of the method arguments, the object and more!
With after_do both the arguments to the method you are attaching the callback to and the object for which the callback is executed are passed into the callback block.
So if you have a method that takes two arguments you can get those like this:
MyClass.after :two_arg_method do |argument_one, argument_2| something end
The method name is passed in as the third argument:
MyClass.before :two_arg_method do |argument_one, argument_2, method_name| something end
The method name is passed for convenience if you do logging for instance. If you start doing
case on the method name, rather think about if you should use different callbacks for the different methods.
Another argument that is passed in, but only for
after is the return value of the method so you can do:
MyClass.after :two_arg_method do |arg1, arg2, name, return_value| report return_value end
The object itself is passed in as the last block argument finally so all arguments together are:
MyClass.after :method do |arg1, arg2, name, return_value, object| magic end # remember before doesn't have the return value MyClass.before :method do |arg1, arg2, name, object| other_magic end
Why this order of arguments? Well at first there are the arguments related to the method itself (arguments, name and optional return value) and then there is the object.
Of course you can just grab the object, if you're not interested in all the method related data, by using the splat operator to soak up all the other arguments:
MyClass.after :two_arg_method do |*, obj| fancy_stuff(obj) end
If you do not want to get a hold of the method arguments or the object, then you can just don't care about the block parameters and can leave them out :-)
Check out the getting a hold sample for more.
Attaching a callback to multiple methods
In after_do you can attach a callback to multiple methods by just listing them:
SomeClass.after :one_method, :another_method do something end
Or you could pass in an Array of method names:
SomeClass.after [:one_method, :another_method] do something end
So for example if you have an activity and want the activity to be saved every time you change it, but you don't want to mix that persistence concern with what the activity actually does you could do something like this:
persistor = FilePersistor.new Activity.extend AfterDo Activity.after :start, :pause, :finish, :resurrect, :do_today, :do_another_day do |activity| persistor.save activity end
Doesn't that seem a lot drier then calling some save method manually after each of those in addition to separating the concerns?
Attaching multiple callbacks to the same method
A method can have as many callbacks as a Ruby Array can handle (although I do not recommend you to have many callbacks around). So this works perfectly fine:
MyClass.after :method do something end MyClass.after :method do another_thing end
The callbacks are executed in the order in which they were added.
Working with inheritance
after_do also works with inheritance. E.g. if you attach a callback to a method in a super class and that method is called in a sub class the callback is still executed.
See this sample:
class A def a # ... end end class B < A end A.extend AfterDo A.after :a do puts 'a was called' end b = B.new b.a #prints out: a was called
Working with modules
after_do works with modules just like it works with classes from version 0.3.0 onwards. E.g. you can just do:
class MyClass include MyModule # .... end MyModule.extend AfterDo MyModule.after :some_method do cool_stuff end MyClass.new.some_method # triggers callback
Working with module/class/singleton methods
after_do also works with module/class/singleton methods whatever you want to call them, e.g. with
MyModule.method, thanks to ruby's awesome object/class system. You just have to attach the callbacks to the singleton class of the object (because that's where the "class side" methods are defined).
Take a look:
module M def self.magic puts 'magic' end end M.singleton_class.extend AfterDo M.singleton_class.after :magic do puts 'after_do is pure magic' end M.magic # Output is: magic after_do is pure magic
Usage from within a class
If you got some repetitive tasks, that need to be done after/before a lot of methods in a class then you can also use after_do for this. This works a bit like
after_action (or *_filter in the Rails 3 lingo) which you might know from Ruby on Rails.
E.g. like this:
class MyClass extend AfterDo # ... after :my_method, :method2, :m3 do |args*, instance| instance.a_method end end
Check out the within class sample for a more complete example.
You can remove all callbacks you added to a class by doing:
Note that this not remove callbacks defined in super/sub classes.
There are some custom errors that after_do throws. When you try to add a callback to a method which that class does not understand it will throw
When an error occurs during one of the callbacks that are attached to a method it will throw
AfterDo::CallbackError with information about the original error and where the block/callback causing this error was defined to help pinpoint the error.
How does it work?
When you attach a callback to a method with after_do what it basically does is it creates a copy of that method and then redefines the method to basically look like this (pseudo code):
execute_before_callbacks return_value = original_method execute_after_callbacks return_value
To do this some helper methods are defined in the AfterDo module. As classes have to extend the AfterDo module all the methods that you are not supposed to call yourself are prefixed with
_after_do_ to minimize the risk of method name clashes. The only not prefixed method are
after_do works on the granularity of methods. That means that you can only attach callbacks to methods. This is no problem however, since if it's your code you can always define new methods. E.g. if you want to attach callbacks to the end of some operation that happens in the middle of a method just define a new method for that piece of code.
I sometimes do this for evaluating a block, as I want to do something when that block finished evaluating so I define a method
eval_block wherein I just evaluate the block.
If other classes or modules define
remove_all_callbacks methods you might run into problems. One of those examples is ActionCable and other classes that might interact with ActiveSupport's callback code.
For this case AfterDo has an
AfterDo::AlternativeNaming module that you can extend in AfterDos stead just like you would normally do. Then all these methods are prefixed with
ad_ to avoid naming clashes.
class WithClashes extend AfterDo::AlternativeNaming # ... ad_after :some_method do magic end end
Those names aren't the nices, now are they? Well, lucky you! You can easily define your own interface into
AfterDo with your own method names as all methods live in
AfterDo::Core and you just need to define which methods call them. For example:
module MyOwnAfterDo include AfterDo::Core def later(*methods, &block) _after_do_define_callback(:after, methods, block) end def earlier(*methods, &block) _after_do_define_callback(:before, methods, block) end def forget_it_all _after_do_remove_all_callbacks end end
Which you can then use as you'd expect, see the sample for some more detail
Is this a good idea?
Always depends on what you are doing with it. As many things out there it has its use cases but can easily be misused.
- Get cross cutting concerns packed together in one file - don't have them scattered all over your code base obfuscating what the real responsibility of that class is
- Don't repeat yourself, define what is happening when in one file
- I feel like it helps the Single Responsibility principle, as it enables classes to focus on what their main responsibility is and not deal with other stuff. I initially wrote this gem when I wanted to decouple an object of my domain from the way it is saved.
- You lose clarity. With callbacks after a method it is not immediately visible what happens when a method is called as some behavior might be defined elsewhere.
- You could use this to modify the behaviour of classes everywhere. Don't. Use it for what it is meant to be used for - a concern that is not the primary concern of the class you are adding the callback to but that class is still involved with.
A use case I feel this is particularly made for is redrawing. That's what we use it for over at shoes4. E.g. we have multiple objects and different actions on these objects may trigger a redraw (such changing the position of a circle). This concern could be littered all over the code base. Or nicely packed into one file where you don't repeat yourself for similar redrawing scenarios and you see all the redraws at one glance. Furthermore it makes it easier to do things like "Just do one redraw every 1/30s" (not yet implemented).
Does it work with Ruby interpreter X?
Thanks to the awesome travis CI the specs are run with CRuby 1.9.3, 2.0, 2.1, 2.2, 2.3, 2.4 and JRuby 1.7, 9.0 and 9.1. It should work with rubinius, but some problems lead me to remove it from the build matrix.
So in short, this should work with all of them and is aimed at doing so :-)
Contributions are very welcome. Whether it's an issue or even a pull request. For pull requests you can use the following flow:
- Fork it
- Create your feature branch (
git checkout -b my-new-feature)
- Commit your changes (
git commit -am 'Add some feature')
- Push to the branch (
git push origin my-new-feature)
- Create new Pull Request
I'd also really appreciate spec only pull requests or bug reports with a failing spec/minimal example as this makes fixing it a lot easier =)
Thanks in advance for all contributions of any kind!