Modules, Roles, Mixins, and *ables in Ruby

Prerequisites

Blocks

Modules

Difference between including and extending Modules

Difference between instance and class methods

Demonstration

One of the most common problems that seem to naturally arise in code is handling objects that share a role. This tends to be an issue that is not immediately apparent, but as the application grows it begins to present itself. Let's illustrate this with a concrete example taken from the code used in this blog. A lot of this code will be ActiveRecord syntax, but the underlying concepts can be applied to plain old Ruby objects as well. When laying out out the code for the blog we have objects for Posts and BookReviews that look like the following:

class Post < ActiveRecord :: Base belongs_to :author , class_name: 'User' validates_presence_of :title , :body , :author validates_length_of :title , maximum: 244 validates_presence_of :author validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug before_save :set_published_at_date def to_param slug end def self . published where ( published: true ) end def self . sorted_by_published_date order ( published_at: :desc ) end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end def set_published_at_date if published_changed? ( from: false , to: true ) self . published_at = Date . today end end end

class BookReview < ActiveRecord :: Base belongs_to :author , class_name: 'User' validates_presence_of :book_title , :body , :book_author validates_length_of :book_title , :book_author , maximum: 244 validates_presence_of :author validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug before_save :set_published_at_date def to_param slug end def self . published where ( published: true ) end def self . sorted_by_published_date order ( published_at: :desc ) end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end def set_published_at_date if published_changed? ( from: false , to: true ) self . published_at = Date . today end end end

Let's go through this code a bit. You'll notice that despite being two different objects, they have quite a bit of behavior in common. To start, they both belong to an Author and validate that an author is present. Additionally they both have slugs for friendly urls, a call to the method #parameterize_slug to ensure the slug is URL friendly, and some validations to ensure the URL is present, unique, and it fits in the DB. Finally both of these objects can be marked as published and have scopes for filtering based on whether they're published or not.

Looking at this code we can see a lot of duplicate code. Both of these objects share similar roles and these roles have the same behavior. You could say they're both sluggable, publishable, and authorable. To refactor this duplicate code we should use Ruby's module. Ruby's module will allow us to 'mixin' common code to objects that share roles. Let's start with the code that makes an object play the authorable role.

module Authorable def self . included ( base ) base . class_eval do belongs_to :author , class_name: 'User' validates_presence_of :author end end end

This is some dense code if you've never seen this pattern before, so let's step through it. The method .included is a built in hook method that gets called when a Ruby module is included in a class. The base argument is simply the included class. So by including the Authorable module into the Post class, the .included method will be called with the Post class set to base . Since base is now equal to Post we can open up the Post class can evaluate code using Ruby's class_eval method. The code inside the block will be evaluated as if it were in the Post class.

Note: This pattern is so common that the Rails framework actually provides a special module for this type of refactoring that's called a Concern. Feel free to use this module if you like, however I'm using the traditional way so we can use it without ActiveSupport.

Now that we lumped all the code related to making an object play the authorable role into the Authorable module, let's rewrite our Post and BookReview classes to use our new module.

class Post < ActiveRecord :: Base include Authorable validates_presence_of :title , :body , :author validates_length_of :title , maximum: 244 validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug before_save :set_published_at_date def to_param slug end def self . published where ( published: true ) end def self . sorted_by_published_date order ( published_at: :desc ) end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end def set_published_at_date if published_changed? ( from: false , to: true ) self . published_at = Date . today end end end

class BookReview < ActiveRecord :: Base include Authorable validates_presence_of :book_title , :body , :book_author validates_length_of :book_title , :book_author , maximum: 244 validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug before_save :set_published_at_date def to_param slug end def self . published where ( published: true ) end def self . sorted_by_published_date order ( published_at: :desc ) end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end def set_published_at_date if published_changed? ( from: false , to: true ) self . published_at = Date . today end end end

In the end we removed the duplication, but more importantly we learned a pattern that we can apply to the other roles these two objects have in common. Let's next tackle the common code that makes these objects publishable. Again, we'll start by creating a new Publishable module to put code for our publishable role.

module Publishable module ClassMethods def published where ( published: true ) end def sorted_by_published_date order ( published_at: :desc ) end end def self . included ( base ) base . extend ( ClassMethods ) base . class_eval do before_save :set_published_at_date end end def css_classes if published? return "published" else return "not-published" end end private def set_published_at_date if published_changed? ( from: false , to: true ) self . published_at = Date . today end end end

You'll notice this module has a bit more to it than the Authorable module. Let's walk through the new changes. Right away you see that we have a module within the Publishable module called ClassMethods . We're going to use the ClassMethods module as a container for defining methods that we want to add as class methods (as opposed to instance methods) to our publishable objects. In our .included hook method that we used before, you'll notice that in addition to evaluating code we also extend our base class with the ClassMethods module. This adds (or mixes in) the methods in ClassMethods with the base or publishable class, but since we're using extend they're added as class methods, not instance methods. Lastly, we have the #css_classes and #set_published_at_date methods. These are instance methods and will automatically be included as instance level methods when the module is included. Once again let's refactor our Post and BookReview classes.

class Post < ActiveRecord :: Base include Authorable include Publishable validates_presence_of :title , :body , :author validates_length_of :title , maximum: 244 validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug def to_param slug end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end end

class BookReview < ActiveRecord :: Base include Authorable include Publishable validates_presence_of :book_title , :body , :book_author validates_length_of :book_title , :book_author , maximum: 244 validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug def to_param slug end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end end

Things are really starting to get cleaned up and duplicate lines of code are disappearing. Let's use the same pattern one last time for removing the duplication when it comes to the sluggable role. Once again we'll create a Sluggable module to correspond to the sluggable role and add the related code to the module.

module Sluggable def self . included ( base ) base . class_eval do validates_presence_of :slug validates_uniqueness_of :slug , case_sensitive: false validates_length_of :slug , maximum: 244 before_validation :parameterize_slug end end def to_param slug end private def parameterize_slug self . slug = slug . to_s self . slug = slug . parameterize end end

By now you are familiar with everything this module is doing. We are evaluating some code in the context of the included sluggable class within class_eval block and moving the instance methods relevant to the sluggable role into the module which will be added to the to the sluggable objects that include this module. Let's look at the final version of our Post and BookReview classes.

class Post < ActiveRecord :: Base include Authorable include Publishable include Sluggable validates_presence_of :title , :body , :author validates_length_of :title , maximum: 244 end

class BookReview < ActiveRecord :: Base include Authorable include Publishable include Sluggable validates_presence_of :book_title , :body , :book_author validates_length_of :book_title , :book_author , maximum: 244 end

Those classes are really compact now. We also now have the neat side effect that when we add other models to our blog, adding roles will be trivially easy. For example, if we decide we want to add a Tags model, all we have to do is include the functionality we want. Tags don't need to play the roles of authorable or publishable, but perhaps we want each Tag to have its own URL. To do this we can simply include the Sluggable module and be done with it (since this is technically a DB backed application we'll need to adjust the DB accordingly as well).

Warnings

While this pattern is powerful there are trade-offs we have to consider. When including modules, the functionality behind each role is now not as apparent. Someone who isn't familiar with your code might wonder where all the functionality is hidden. This also adds a bit of cognitive load for the programmer as they now have code for one object in 3 additional different places they must consider. When refactoring out into modules, or anytime when using inheritance, you'll want to make sure you're constantly asking yourself, will other programmers be able to easily navigate the code and find what they need.

We could, for example, create another module called Broadcastable that would look something like:

module Broadcastable include Authorable include Publishable include Sluggable end

And then include this in our Post and BookReview classes. While this does DRY up the code a bit, I feel that it adds too much complexity and cognitive load. Its not quite as clear as to what Broadcastable does and adds another layer in the inheritance tree that programmers must process.

Another thing to be careful with is using this pattern simply to remove duplicate code. Its important to consider that the purpose of the duplicate code is the same as opposed to having duplicate code purely because of coincidence. If the purpose is aligned, then its much more likely the future changes will be compatible with all involved objects. If the duplicate code exists between objects coincidentally, then its much more likely that the duplicate code may diverge in the future. Sometimes you might even want to hold off refactoring until further down the line, when the true roles of objects become more clear.

With these warnings in mind, factoring out common code that objects share by virtue of having a role into a module is a great way to organize shared behavior.

See More:

To see how to test this pattern, you can view the source code for this blog. It makes use of rspec's Shared Examples. In minitest you would simply use modules!