I\'m trying to understand the purpose of a Ruby module from a design pattern perspective.
Is a Ruby module essentially just a class that is only initialized once?
Modules have two uses in Ruby: namespacing of constants and as mixins.
Namespacing of constants simply means that in
FOO = 1
module Bar
FOO = 2
end
module Baz
FOO = 3
end
there are three different FOOs in three different namespaces: one in the global namespace (which is actually Object), one in Bar and one in Baz.
The more interesting use case is mixins: a mixin is basically a class which is parameterized over its superclass. Or, to put it another way: a mixin is a class that can appear multiple times in the inheritance graph, each time with a different superclass.
Contrast this with multiple inheritance: in multiple inheritance, a class can only appear once in the inheritance graph, but it may have multiple superclasses. A mixin may appear multiple times in the inheritance graph, but each occurrence has only one superclass.
In particular, what happens in Ruby when you mix a module M into a class C is that an actual class (a so-called include class) is created (let's call it M′) whose method table, constant table and variable table pointers point to M's method table, constant table and variable table, and that class M′ becomes C's superclass with the old superclass becoming M′'s superclass.