after_do

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...)

Installation

Add this line to your application's Gemfile:

gem 'after_do'

And then execute:

$ bundle

Or install it yourself as:

$ gem install after_do

And then you have to require the gem before you can use it:

require 'after_do'

Usage

This section is dedicated to show the general usage and effects of after_do. You can also check out the samples directory or the specs in the spec folder.

General usage

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: MyClass.extend AfterDo. 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 if or 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 before_action/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.

Removing callbacks

You can remove all callbacks you added to a class by doing:

MyClass.remove_all_callbacks

Note that this not remove callbacks defined in super/sub classes.

Errors

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 AfterDo::NonExistingMethodError.

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, before and remove_all_callbacks.

Method granularity

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.

Naming Clashes

If other classes or modules define after, before or 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.

Advantages

• 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.

Drawbacks

• 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 :-)

Contributing

Contributions are very welcome. Whether it's an issue or even a pull request. For pull requests you can use the following flow:

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. 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!