Aug 27, 2007 @ 11:06 am

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.

  1. module DogsRelated
  2.   NBR_OF_DOGS_NEEDED_TO_START_A_DOG_PARTY = 5
  3.   class Dog
  4.     def bark
  5.       puts "Woof…"
  6.     end
  7.  
  8.     def eat
  9.       puts "…"
  10.     end
  11.    
  12.     def wag_tail
  13.       puts "I’m doing this because I’m happy"
  14.     end
  15.  
  16.     def give_the_paw
  17.       puts "Why??"
  18.     end
  19.   end 
  20. end
  21.  
  22. x = 6
  23. charlie = DogsRelated::Dog.new
  24. 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

Bookmark this post : These icons link to social bookmarking sites where readers can share and discover new web pages.
  • DZone
  • Reddit
  • del.icio.us
  • Digg
  • Furl
  • Technorati
  • StumbleUpon
Rate this post :
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 3.33 out of 5)
Loading ... Loading ...
Posted under : In depth
9 Comments
MyAvatars 0.2

Just a comment in general. I really like your articles. You manage to explain some of the more obscure facets of Ruby in a very understandable way. Thanks and keep up the good work!

Comment by : Jan Caals
— August 30, 2007 @ 4:21 am

MyAvatars 0.2

@Jan Caals, Thanks a lot for your comment. This is the kind of comment that gives me confidence and a nice little boost :) Thanks again and I’m glad you like the articles!

Comment by : Frank
— September 1, 2007 @ 7:14 am

MyAvatars 0.2

great post.
I agree with Jan - your writing style is what is missing in a lot of book and tutorials.

I am waiting for the second part!

Comment by : Oren
— September 2, 2007 @ 12:23 am

MyAvatars 0.2

Thanks for the kind words Oren. Again, it’s really appreciated

Comment by : Frank
— September 3, 2007 @ 1:41 pm

MyAvatars 0.2

[…] the first part, we learned that a module was a namespace, a way to regroup similar things to help us organize our […]

— September 12, 2007 @ 11:44 pm

MyAvatars 0.2

This really got me up to speed again on modules. I only looked at them half heartedly in the past. This and the follow-up got me going. Thanks for the great article.

Comment by : Sam Figueroa
— October 29, 2007 @ 12:35 pm

MyAvatars 0.2

Nice

Comment by : Ivan
— November 21, 2007 @ 12:02 pm

MyAvatars 0.2

Nice

Comment by : Iannis
— January 9, 2008 @ 12:08 pm

MyAvatars 0.2

regles poker texas holdem…

Esta noche apuesta dinero portal strip poker on line tavolo multigicotori poker game on line poker casinos internacionales internet…

— July 8, 2008 @ 4:14 pm




Leave a comment
Name (required)
Email (will not be publish) (required)
Website