Ruby supports single inheritance (<) — a class inherits from one superclass. When you call a method, Ruby searches a well-defined method lookup path (the ancestor chain, including mixed-in modules) to find it. Understanding this path explains how inheritance and mixins resolve methods.
() = = name
=
<
.new().speak
.new().fetch
A subclass (Dog < Animal) inherits the superclass's methods and instance variables, and can override methods. super calls the parent's version.
class Dog < Animal
def initialize(name, breed)
super(name) # call Animal#initialize
@breed = breed
end
def speak
super + " (woof)" # super (no parens) passes the same args; here calls Animal#speak
end
end
# Ruby searches for a method in this ORDER (the ancestors chain):
Dog.ancestors
# => [Dog, <included modules>, Animal, <Animal's modules>, Object, Kernel, BasicObject]
# lookup: the class itself → its included MODULES (last included first) →
# the superclass → ITS modules → ... up to BasicObject
When you call a method, Ruby walks the ancestor chain (Class.ancestors): the class itself, then its included modules (mixins — most recently included first), then the superclass and its modules, up to BasicObject. The first match wins. This single path explains how inheritance AND mixins resolve together.
module Swimmer
def move = "swimming"
end
class Fish < Animal
include Swimmer # Swimmer is inserted into the lookup path (before Animal)
end
# Fish.ancestors → [Fish, Swimmer, Animal, ...] — a module's methods come before the superclass's
Understanding inheritance and the method lookup path is important Ruby knowledge for both designing class hierarchies and — especially — understanding how Ruby resolves methods when inheritance and mixins combine.
Ruby's single inheritance (<) provides code reuse via "is-a" relationships, with super to call parent implementations.
But the more distinctive and important concept is the method lookup path (the ancestor chain): when a method is called, Ruby searches in a well-defined order — the class itself, its included modules (mixins, most-recently-included first), then the superclass and its modules, up to BasicObject — and the first match wins.
Understanding this single, unified lookup path is crucial because it explains how inheritance and mixins resolve together (modules are inserted into the chain, their methods taking precedence over the superclass's), which clarifies otherwise-confusing behavior about which method actually gets called when you have both inheritance and multiple mixins.
This is particularly important in Ruby given how heavily it uses mixins — knowing that Class.ancestors shows the exact lookup order, and how modules fit into it, lets you reason about and debug method resolution.
Understanding inheritance, super, and especially the method lookup path (how the ancestor chain resolves methods across classes and mixed-in modules) is important, frequently-relevant knowledge for working with Ruby's class system, debugging "which method is being called?" questions, and designing class/module hierarchies — and it's a common interview topic that reflects deeper understanding of Ruby's object model and its distinctive combination of single inheritance with powerful mixins.