Almost every languages have variables, constants, classes and objects… but who knew about modules before Ruby was invented? A ruby module is not that easy to define because it can serve two different purposes. If we introduce the word Mixin in our definition, we’re diving into the more complex side of what modules are. Today, I will talk about modules without talking about the mixin functionality.
A module without the mixin functionality?
If the concept of mixins didn’t exist, modules would be so simple… and perhaps a little bit boring. At its heart, a module is a component used to logically regroup similar things. By doing so, 3 good things happen : #1 Your code becomes more organized. #2 You eliminate the risk of name clashes. #3 You become rich, extremely smart AND you become able to move very heavy stuff with the power of your mind. Today, I’d like that you concentrate on the 2 first points. You probably already guessed it right : This is the definition of a namespace.
Sometime, when the application you’re working on is rather big, you may need an additional level to regroup things together. May it be methods, constants or classes, it can makes sense to put all of these things under a common parent for the sake of understanding.
But aren’t classes fit this purpose?
Yes… but not always. Generally, a class contains variables and methods that describe the state and the behavior of an entity (a dog, a user, a story, etc.). A module, on the other hand, is just a name that regroup whatever you think is related. For example, say I have the class “Dog”. This class contains several variables and methods that describe the state and the behavior of a dog. Now, say that I also have a constant called NBR_OF_DOGS_NEEDED_TO_START_A_DOG_PARTY. I *could* put this constant in the class Dog… but it would not be a good idea all that much. This constant isn’t an attribute that describe the state of a dog, it is just something that is related to dogs in general. An idea could be to define a module named DogsRelated and put the class “Dog” as well as the constant NBR_OF_DOGS_NEEDED_TO_START_A_DOG_PARTY in it.
Another benefit of doing this is that this new module will “protect” the names that it contains. So if you have installed a 3rd party library that also contains a class named Dog… you will still be able to specify which of these classes you want to use at any moment.

module DogsRelated
  NBR_OF_DOGS_NEEDED_TO_START_A_DOG_PARTY = 5
  class Dog
    def bark
      puts "Woof..."
    end
    def eat
      puts "..."
    end
    def wag_tail
      puts "I'm doing this because I'm happy"
    end
    def give_the_paw
      puts "Why??"
    end
  end
end
x = 6
charlie = DogsRelated::Dog.new
charlie.wag_tail if x >= DogsRelated::NBR_OF_DOGS_NEEDED_TO_START_A_DOG_PARTY

We use the “::” notation to access the constants located inside the module. (The class Dog is also a constant). Remember that the dot “.” is reserved for methods calling.
… and that’s about it. But wait, there is more.
The real interest of ruby modules comes with mixins … more on that in the next part