CSC/ECE 517 Fall 2011/ch4 4c dm

Modules

Modules provide a structure to collect Ruby classes, methods, and constants into a single, separately named and defined unit. This is useful so that one can avoid clashes with existing classes, methods, and constants, and also so that you can add (mix in) the functionality of modules into your classes. The definition of a module is very similar to a class. Also, modules and classes are closely related. The Module class is the immediate ancestor of the Class class. Just like a class, a module can contain constants, methods and classes.

In Ruby programming language , a module is defined in the following way

 module <module name>
   statement1
   statement2
   ...........
 end

Consider for example ,a module called MyModule , which defines the happy and the sad times.

 module MyModule 
  GOODMOOD = "happy"
  BADMOOD = "sad" 
  def greet 
  return "I'm #{GOODMOOD}. How are you?"
  end
  def MyModule.greet
  return "I'm #{BADMOOD}. How are you?" 
  end
 end 

The above represents a module MyModule with a constant GOODMOOD and an “instance method” greet. In addition to instance methods a module may also have module methods. Just as class methods are prefixed with the name of the class, module methods are prefixed with the name of the module as shown above in MyModule.greet.

In spite of their similarities, there are two major features which classes possess but which modules do not: instances and inheritance. Classes can have instances (objects), superclasses (parents) and subclasses (children); modules can have none of these. Inspite of inability of the modules to be initialized and inherited., They provide a namespace and prevent name clashes and they implement the mixin facility.

Modules as Namespaces

Modules can be considered as a named ‘wrapper’ around a set of methods, constants and classes. The various bits of code inside the module share the same ‘namespace’ so they are all visible to each other, but not visible to code outside the module.

Consider the example of the MyModule described above

We can access the module constants just as we would access class constants using the :: scope resolution operator like this:

 puts(MyModule::GOODMOOD)   #->  happy
 puts(MyModule::BADMOOD)   #->  sad

We can access module methods using dot notation – that is, specifying the module name followed by a period and the method name For example

 puts( MyModule.greet )     # ->  I’m sad. How are you?

Since modules define a closed space, we cannot access the instance method “greet” from outside the module.

 puts greet   # -> NameError: undefined local variable or method `greet' for main:Object

In case of classes , we could have created instances of the class which would all have access to the instance methods of the class. However modules cannot be instantiated. This is where mixins come into picture.

Mixins

A mixin is a class that is mixed with a module or a set of modules. In other words the implementation of the class and module are intertwined and combined. The real usage of a mixin is exploited when the code in the mixin starts to interact with code in the class that uses it.In order to mix the modules into the class we make use of the “include” method. As it is included, the instance methods in the modules can be used just as though it were a normal instance method within the current scope.

The process of including a module is also called ‘mixing in’ – which explains why included modules are often called ‘mixins’. When you mix modules into a class definition, any objects created from that class will be able to use the instance methods of the mixed-in module just as though they were defined in the class itself.

 class MyClass
  include MyModule 
  def sayHi
  puts( greet )
  end 
 end 

Not only can the methods of this class access the greet method from MyModule, but so too can any objects created from the class:

 ob = MyClass.new 
 ob.sayHi     # -> I'm happy. How are you?
 puts(ob.greet)   # -> I'm happy. How are you?