You’ve probably already heard of Ruby’s metaprogramming capabilities but you may either think it is only suitable for building frameworks and DSLs or you don’t know when to make use of it. Here we’ll show you how little doses of metaprogramming can help to dry up your Rails app. It’s definitely a tool to keep in your toolbelt but it generally raises the overall abstraction of your code. So, watch out!<\/p>\n
Modules in Ruby, besides providing namespacing, implement the mixin facility. However, modules may depend on the object they are included in. You may want to execute funcionality of your brand new module from an ActiveRecord callback. Let’s start with the following model:<\/p>\n
class Membership < ActiveRecord::Base\r\n belongs_to :user\r\n belongs_to :organization\r\nend<\/pre>\nLet's say we want to track down whenever a membership is deleted. Easy enough. We just add the following:<\/p>\n
class Membership < ActiveRecord::Base\r\n include MembershipDestroyLogger\r\n \r\n belongs_to :user\r\n belongs_to :organization\r\n \r\n # Warning! this couples Membership with MembershipDestroyLogger\r\n after_destroy :log_model_deletion\r\nend\r\n\r\nmodule MembershipDestroyLogger\r\n def log_model_deletion\r\n Rails.logger.warn(\"[MembershipDestroyLogger] Deleted Membership #{id}\")\r\n end\r\nend<\/pre>\nThe `MembershipDestroyLogger` nicely wraps it up. Note that `Membership` must implement the `after_destroy` callback in order for the module to work. Unfortunately, this couples `Membership` with `MembershipDestroyLogger`.<\/p>\n
Let's say that now we also want to keep track of the oauth applications that get removed. That'd involve to implement the `OauthApplicationDestroyLogger`. If we keep implementing more destroy loggers we will soon end up having a bunch of modules containing the same code along with the required callbacks. It's time to dry things up.<\/p>\n
Included hook<\/h3>\n
According to the Ruby documentation<\/p>\n
`included`: Callback invoked whenever the receiver is included in another module or class<\/p><\/blockquote>\n
It basically executes whatever code you specified whenever a module is included into a class.<\/p>\n
module Foo\r\n def self.included(base)\r\n puts 'Foo has been included somewhere'\r\n end\r\nend<\/pre>\nNote the method receives an argument. That represents the class where the module has been included into. That's all we need. We can now abstract our destroy loggers.<\/p>\n
module DestroyLogger\r\n def self.included(base)\r\n base.after_destroy :log_model_deletion\r\n end\r\n\r\n private\r\n\r\n def log_model_deletion\r\n Rails.logger.warn(\"[DestroyLogger] Deleted #{self.class} #{id}\")\r\n end\r\nend<\/pre>\n`base` is the model we include the module into, so the module can add the required `after_destroy` callback itself. Furthermore, as `self` points to model we can retrieve the model's class name. <\/p>\n
Voil\u00e0! we can remove all the previous destroy loggers and just drop the module in whatever module we want to keep track of. So, finally our models look like this:<\/p>\n
class Membership < ActiveRecord::Base\r\n include DestroyLogger\r\nend\r\n\r\nclass OauthApplication < ActiveRecord::Base\r\n include DestroyLogger\r\nend<\/pre>\nConclusions<\/h3>\n
As you can see, there is no need for digging into complex and abstract metaprogramming stuff to benefit from Ruby's features. Little doses of metaprogramming can already improve your code and lead you to a better world.<\/p>\n
The `included` hook is also the underlying implementation of ActiveSupport::Concern's included method<\/a>. With this and other techniques, ActiveSupport::Concern eases the implementation of the mixin pattern considerably.<\/p>\n
References<\/h3>\n
If you want to expand your Ruby metaprogramming skills further, Metaprogramming Ruby 2: Program Like the Ruby Pros<\/a> is a recommended reading. Specially its ActiveSupport's Concern Module<\/em><\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
You’ve probably already heard of Ruby’s metaprogramming capabilities but you may either think it is only suitable for building frameworks and DSLs or you don’t know when to make use of it. Here we’ll show you how little doses of metaprogramming can help to dry up your Rails app. It’s definitely a tool to keep …