Learning To Code

Ruby’s Modules and Mixins

Flatiron School / 30 April 2015

This post was written by Flatiron student Jon Tow and originally appeared on his blog “My Journey Mining Rubys & Riding the Rails Coaster“. Check it out to learn more about Ruby and the art of selecting the perfect gif.

In this post, I will cover what modules and mixins are and when to use them. We briefly covered how to implement modules during one of my classes at the Flatiron School. I was curious about when one should use modules so I did some research. I had more questions when I read that modules implement the mixin facility. What is a mixin? I looked up mixin’s and was confused on how modules and mixins were related. Mixins are a way of adding a collection of methods and constants to a class. But doesn’t that sound like what modules do? Does modules == mixins? After digging around, I think I found the exact meaning of both words and their uses.


A module is just a ruby file, with the collection of code to be shared across classes, for example:

How do you give classes access to this module and therefore the “be_cute” method? You will use the mixin concept to inject the code into classes by using “include”!

Now if I create a new instance of the class, I have the ability to call the module’s method:



The concept of mixins is to share or “mix in” code from another source. By using the statement “include” followed by the module’s name, I can give the class access to the module’s contents.

Now that we have the definitions of modules and mixins lets talk about when to use a module. You can say that in my previous example, the Kitten class should just have the “be_cute” method directly in its class. But what if I had other classes that wanted access to the method, such as a Puppy or Bunny classes? If I had more than one instance of a behavior that can be cut out and separated into a module, then I should do it to for the sake of removing repeating code.


Now lets say instead of having a module, I create a class called Animal that all animals inherit from. It would make sense to put in the be_cute method in the Animal class since Kitten, Puppy, and Bunny classes are animals and they are all cute.

Wrong! In this case, not all animals are adorable! Take a blobfish for instance:


I wouldn’t want to give the Blobfish class access to the be_cute method so I will need to take out the “be_cute” method from the Animal class. I can utilize the Adorable module and include it to the Kitten, Puppy, and Bunny classes since I want those specific classes to share that behavior.

One note I would like to mention is that in Ruby, a class can only inherit from one class. If the Kitten class inherits from the Animal class, I wouldn’t be able to make a class for specific behaviors and let the Kitten class inherit from that. This is what makes modules and mixins powerful. I can include modules into any class and that class would be able to call upon methods it otherwise wouldn’t be able to.

That’s it for now. I have decided to skip on discussing the module’s other function, namspaces, because I most likely will not need to use it in the early stages of my studying.

I don’t want to leave a bad taste in anyone’s mouth, so here are some cat gifs.







image        image


Five Lessons for Teaching High Schoolers to Code Previous Post MY ASSETS AND HEROKU ARE IN A FIGHT Next Post