20141110 Flatiron School-47
Learning To Code

Ruby’s Modules and Mixins

Flatiron School / 30 April 2015
SHARE:

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.

Module

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:

image

Mixins

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.

Inheritance

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:

image

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.

imageimage
image

 

 

 

 

 

image        image

 

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