100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Ruby

Modules and Mixins

Discover how Ruby modules group related methods and constants, and how mixing them into classes with include, extend, and prepend enables flexible code reuse without multiple inheritance.

Object-Oriented RubyIntermediate10 min readJul 9, 2026
Analogies

Modules and Mixins

A module, defined with the module keyword, is a collection of methods, constants, and other modules/classes that -- unlike a class -- cannot be instantiated with .new and cannot be subclassed. Modules serve two main purposes in Ruby: acting as namespaces to group related classes and constants together (avoiding naming collisions), and acting as mixins -- reusable bundles of behavior that get 'mixed into' a class's ancestor chain, giving Ruby much of the power of multiple inheritance without its complications.

🏏

Cricket analogy: A module acting as a mixin is like a fielding-drills playbook that any team can adopt without that playbook itself ever fielding a match, giving multiple squads shared techniques without one team subclassing another.

include, extend, and prepend

include mixes a module's methods in as instance methods of the including class, inserting the module into the ancestor chain directly above the class itself. extend mixes a module's methods in as singleton (class-level or object-level) methods instead. prepend also inserts the module into the instance method lookup chain, but ahead of the class itself, meaning the module's methods take priority over the class's own definitions -- useful for wrapping or decorating existing behavior while still being able to call super to reach the original method.

🏏

Cricket analogy: include adding a module's methods to the ancestor chain is like a franchise adopting a shared bowling-technique manual directly into its coaching hierarchy, while prepend is like a specialist consultant whose advice overrides the head coach's own calls first, letting the coach's original method still be reached via super.

ruby
module Loggable
  def log(message)
    puts "[#{self.class}] #{message}"
  end
end

module Auditable
  def save
    puts "auditing before save"
    super
  end
end

class Order
  include Loggable
  prepend Auditable

  def save
    puts "saving order"
  end
end

Order.new.log("created")   # => "[Order] created"
Order.new.save
# => "auditing before save"
# => "saving order"

Modules as namespaces

Wrapping related classes inside a module creates a namespace, preventing name collisions between similarly named classes in different parts of a large application -- a pattern used heavily by gems and Rails engines. You reference a namespaced constant with the :: scope resolution operator, e.g. Payments::CreditCard versus a hypothetical unrelated Shipping::CreditCard.

🏏

Cricket analogy: Namespacing classes inside a module is like two different leagues both having a team called 'Strikers' without confusion, since you always refer to them fully as IPL::Strikers versus BBL::Strikers.

ruby
module Payments
  class CreditCard
    def charge(amount)
      "Charged $#{amount} via Payments::CreditCard"
    end
  end
end

Payments::CreditCard.new.charge(50)

Enumerable and Comparable: mixins in the standard library

Ruby's own standard library relies heavily on the mixin pattern: including Comparable in a class and defining a single <=> (spaceship) method automatically grants that class <, >, ==, between?, and clamp. Including Enumerable and defining a single each method automatically grants dozens of methods like map, select, sort, reduce, and include?. This is the clearest real-world demonstration of why mixins are powerful: a tiny amount of code in your class unlocks a large, well-tested behavior surface from the module.

🏏

Cricket analogy: Including Comparable and defining <=> to unlock <, >, between? is like a selector defining one ranking formula and instantly being able to compare, rank, and shortlist any two players without writing separate comparison logic for each stat.

ruby
class TemperatureReading
  include Comparable
  attr_reader :celsius

  def initialize(celsius)
    @celsius = celsius
  end

  def <=>(other)
    celsius <=> other.celsius
  end
end

TemperatureReading.new(10) < TemperatureReading.new(20)   # => true

Because include inserts a module directly above the including class in the ancestor chain, a class's own method definitions still take priority over an included module's same-named method. prepend flips this priority so the module's method runs first (and can call super to delegate to the class's original method) -- a distinction that trips up many developers new to Ruby's mixin system.

Because Ruby resolves methods by walking the ancestor chain and stopping at the first match, including two modules that define a method with the same name means only the more recently included one 'wins' silently -- there's no compiler error warning you about the conflict, so name collisions between mixins can cause confusing bugs that only surface at runtime.

  • Modules group methods/constants as namespaces and/or provide reusable behavior as mixins; they cannot be instantiated.
  • include adds a module's methods as instance methods, inserted into the ancestor chain just above the including class.
  • extend adds a module's methods as methods on the class/object itself rather than on instances.
  • prepend inserts a module ahead of the class in the lookup chain, letting it intercept and call super to reach the class's own method.
  • Including Comparable (with <=>) or Enumerable (with each) unlocks many standard methods from a minimal implementation.
  • Conflicting method names between multiple included modules resolve silently by ancestor-chain order, with no warning.

Practice what you learned

Was this page helpful?

Topics covered

#Ruby#RubyStudyNotes#Programming#ModulesAndMixins#Modules#Mixins#Include#Extend#StudyNotes#SkillVeris