The first answer is good and gives some structural answers, but another approach is to think about what you're doing. Modules are about providing methods that you can use across multiple classes - think about them as "libraries" (as you would see in a Rails app). Classes are about objects; modules are about functions.
For example, authentication and authorization systems are good examples of modules. Authentication systems work across multiple app-level classes (users are authenticated, sessions manage authentication, lots of other classes will act differently based on the auth state), so authentication systems act as shared APIs.
You might also use a module when you have shared methods across multiple apps (again, the library model is good here).
+-----------------------------------------------------------------------------+
¦ ¦ class ¦ module ¦
¦---------------+---------------------------+---------------------------------¦
¦ instantiation ¦ can be instantiated ¦ can *not* be instantiated ¦
¦---------------+---------------------------+---------------------------------¦
¦ usage ¦ object creation ¦ mixin facility. provide ¦
¦ ¦ ¦ a namespace. ¦
¦---------------+---------------------------+---------------------------------¦
¦ superclass ¦ module ¦ object ¦
¦---------------+---------------------------+---------------------------------¦
¦ methods ¦ class methods and ¦ module methods and ¦
¦ ¦ instance methods ¦ instance methods ¦
¦---------------+---------------------------+---------------------------------¦
¦ inheritance ¦ inherits behaviour and can¦ No inheritance ¦
¦ ¦ be base for inheritance ¦ ¦
¦---------------+---------------------------+---------------------------------¦
¦ inclusion ¦ cannot be included ¦ can be included in classes and ¦
¦ ¦ ¦ modules by using the include ¦
¦ ¦ ¦ command (includes all ¦
¦ ¦ ¦ instance methods as instance ¦
¦ ¦ ¦ methods in a class/module) ¦
¦---------------+---------------------------+---------------------------------¦
¦ extension ¦ can not extend with ¦ module can extend instance by ¦
¦ ¦ extend command ¦ using extend command (extends ¦
¦ ¦ (only with inheritance) ¦ given instance with singleton ¦
¦ ¦ ¦ methods from module) ¦
+-----------------------------------------------------------------------------+
Class
When you define a class, you define a blueprint for a data type. class hold data, have method that interact with that data and are used to instantiate objects.
Module
Modules are a way of grouping together methods, classes, and constants.
Modules give you two major benefits:
=> Modules provide a namespace and prevent name clashes. Namespace help avoid conflicts with functions and classes with the same name that have been written by someone else.
=> Modules implement the mixin facility.
(including Module in Klazz gives instances of Klazz access to Module methods. )
(extend Klazz with Mod giving the class Klazz access to Mods methods.)
Bottom line: A module is a cross between a static/utility class and a mixin.
Mixins are reusable pieces of "partial" implementation, that can be combined (or composed) in a mix & match fashion, to help write new classes. These classes can additionally have their own state and/or code, of course.
I'm surprised anyone hasn't said this yet.
Since the asker came from a Java background (and so did I), here's an analogy that helps.
Classes are simply like Java classes.
Modules are like Java static classes. Think about Math class in Java. You don't instantiate it, and you reuse the methods in the static class (eg. Math.random()).
First, some similarities that have not been mentioned yet. Ruby supports open classes, but modules as open too. After all, Class inherits from Module in the Class inheritance chain and so Class and Module do have some similar behavior.
But you need to ask yourself what is the purpose of having both a Class and a Module in a programming language? A class is intended to be a blueprint for creating instances, and each instance is a realized variation of the blueprint. An instance is just a realized variation of a blueprint (the Class). Naturally then, Classes function as object creation. Furthermore, since we sometimes want one blueprint to derive from another blueprint, Classes are designed to support inheritance.
Modules cannot be instantiated, do not create objects, and do not support inheritance. So remember one module does NOT inherit from another!
So then what is the point of having Modules in a language? One obvious usage of Modules is to create a namespace, and you will notice this with other languages too. Again, what's cool about Ruby is that Modules can be reopened (just as Classes). And this is a big usage when you want to reuse a namespace in different Ruby files:
module Apple
def a
puts 'a'
end
end
module Apple
def b
puts 'b'
end
end
class Fruit
include Apple
end
> f = Fruit.new
=> #<Fruit:0x007fe90c527c98>
> f.a
=> a
> f.b
=> b
But there is no inheritance between modules:
module Apple
module Green
def green
puts 'green'
end
end
end
class Fruit
include Apple
end
> f = Fruit.new
=> #<Fruit:0x007fe90c462420>
> f.green
NoMethodError: undefined method `green' for #<Fruit:0x007fe90c462420>
The Apple module did not inherit any methods from the Green module and when we included Apple in the Fruit class, the methods of the Apple module are added to the ancestor chain of Apple instances, but not methods of the Green module, even though the Green module was defined in the Apple module.
So how do we gain access to the green method? You have to explicitly include it in your class:
class Fruit
include Apple::Green
end
=> Fruit
> f.green
=> green
But Ruby has another important usage for Modules. This is the Mixin facility, which I describe in another answer on SO. But to summarize, mixins allow you to define methods into the inheritance chain of objects. Through mixins, you can add methods to the inheritance chain of object instances (include) or the singleton_class of self (extend).
namespace: modules are namespaces...which don't exist in java ;)
I also switched from Java and python to Ruby, I remember had exactly this same question...
So the simplest answer is that module is a namespace, which doesn't exist in Java. In java the closest mindset to namespace is a package.
So a module in ruby is like what in java:
class? No
interface? No
abstract class? No
package? Yes (maybe)
static methods inside classes in java: same as methods inside modules in ruby
In java the minimum unit is a class, you can't have a function outside of a class. However in ruby this is possible (like python).
So what goes into a module?
classes, methods, constants. Module protects them under that namespace.
No instance: modules can't be used to create instances
Mixed ins: sometimes inheritance models are not good for classes, but in terms of functionality want to group a set of classes/ methods/ constants together
Rules about modules in ruby:
- Module names are UpperCamelCase
- constants within modules are ALL CAPS (this rule is the same for all ruby constants, not specific to modules)
- access methods: use . operator
- access constants: use :: symbol
simple example of a module:
module MySampleModule
CONST1 = "some constant"
def self.method_one(arg1)
arg1 + 2
end
end
how to use methods inside a module:
puts MySampleModule.method_one(1) # prints: 3
how to use constants of a module:
puts MySampleModule::CONST1 # prints: some constant
Some other conventions about modules:
Use one module in a file (like ruby classes, one class per ruby file)
Module in Ruby, to a degree, corresponds to Java abstract class -- has instance methods, classes can inherit from it (via include, Ruby guys call it a "mixin"), but has no instances. There are other minor differences, but this much information is enough to get you started.
Basically, the module cannot be instantiated. When a class includes a module, a proxy superclass is generated that provides access to all the module methods as well as the class methods.
A module can be included by multiple classes. Modules cannot be inherited, but this "mixin" model provides a useful type of "multiple inheritrance". OO purists will disagree with that statement, but don't let purity get in the way of getting the job done.
(This answer originally linked to http://www.rubycentral.com/pickaxe/classes.html, but that link and its domain are no longer active.)
Source: Stackoverflow.com