It’s a very common practice in Ruby to use Module mixins to enhance the functionality of a class. In fact, one of the most powerful and useful features of the Ruby language is that it is so easy to do so. Great stuff all around.
Another common pattern, however, is to want to provide some include-time configuration when the module is mixed in. Let’s imagine I’m writing an extension for ActiveRecord that creates a slug based on some field. What I want in the end might be something that looks like this:
class MyModel < ActiveRecord::Base slug :name end OK, that seems easy enough. How can I implement that? Well, there are a number of different ways. I could just re-open ActiveRecord::Base:
module ActiveRecord class Base def self.slug(field) # do some things here... end end end Ruby gives us a lot of rope to implement things in different ways. In this case, it’s given us enough to hang ourselves. Opening existing classes like this is a bit dangerous, escpecially in an environment like Rails that has so much lazy loading of classes. How can we improve on this? Well, we could make our slug extension into a module:
module Sluggable def slug(field) include Sluggable::ActivatedInstanceMethods # do something with field end module ActivatedInstanceMethods # some code here... end end ActiveRecord::Base.extend Sluggable This is a little bit better: we are encapsulating the behavior of Sluggable into its own entity rather than polluting an existing class. This still doesn’t seem quite right, though: why does every ActiveRecord class need to know about this slug method? Ideally I would only modify the behavior of classes that I actually want to implement the slug behavior, not all ActiveRecord classes.
So what’s next? Well, we can do something like this instead:
class MyModel < ActiveRecord::Base extend Sluggable slug :field_name end This works fine, but it’s a little distasteful looking. Why do I need to have two lines of code in my model? Doesn’t that defeat some of the purpose of trying to abstract functionality out into its own little world?
Introducing Imbue
The more I thought about this problem, the more I felt like there needed to be a more primitive implementation of this pattern within Ruby. I want to be able to include a module into a class with the knowledge that the module is going to, in some ways, reconfigure my class with optional arguments that I pass. Of course, some would argue that if we allowed the include keyword to do this we would be stripping modules of their dignity. So can we come up with perhaps a different keyword that represents the pattern of “transformative mixin”? I propose imbue. Imbue means “Inspire or permeate with a feeling or quality” which sounds pretty similar to what we’re trying to accomplish here.
So how can we go about implementing this concept of “imbue”? Here’s a dead-simple version of it:
class Module def imbue(mod, *args) result = include(mod) mod.imbued(self, *args) if mod.respond_to?(:imbued) result end end Well, that’s pretty concise, huh? Surely 7 lines of code can’t have that much effect on our problem area, can they? Here’s what these 7 lines of code let us do:
module Sluggable def self.imbued(base, source, options = {}) base.extend ClassMethods base.send :include, InstanceMethods # additional transformation here end module ClassMethods # relevant class methods end module InstanceMethods # activated instance methods end end class MyModel < ActiveRecord::Base imbue Sluggable, :field_name end In the end, I really like the way this looks. It’s less cryptic than the hide-the-ball class method because it gives us the fully qualified module. It’s more concise than the include-and-class-method strategy because it lets us pass options along with the module we want to include. It’s more Rubyish than the factory pattern, giving us a simple standard method call instead of using metaprogramming to generate an anonymous module. To sum up, I really like it!
This pattern is so commonly used in Ruby that I would almost argue that something akin to imbue should be a part of the language itself. It gives you a great way to encapsulate transformative behaviors that can then be applied generically. What do you think about imbue? Would you like to see it as a gem or even part of Ruby itself? Let me know in the comments.
