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

Inheritance in Ruby

See how Ruby classes extend one another with single inheritance, how `super` calls parent implementations, and how method resolution order determines which method runs.

Object-Oriented RubyIntermediate10 min readJul 9, 2026
Analogies

Inheritance in Ruby

Inheritance lets one class (a subclass) reuse and extend the behavior of another class (its superclass), expressed with the < operator: class Dog < Animal. Ruby supports only single inheritance -- a class can have exactly one direct superclass -- but compensates for the flexibility multiple inheritance would offer through modules and mixins, which are covered separately. Every class you define implicitly inherits from Object (and ultimately BasicObject) unless you specify otherwise, which is why every Ruby object responds to methods like inspect, class, and respond_to? regardless of your own class hierarchy.

🏏

Cricket analogy: class Dog < Animal is like a franchise's academy team inheriting the senior team's training methods with the < operator; a player can belong to only one academy at a time, but every cricketer, regardless of academy, still responds to basic rules like 'follow the umpire,' the way every object inherits from Object.

Overriding methods and calling super

A subclass can override any method it inherits by simply redefining a method with the same name. Inside an overriding method, calling super invokes the superclass's version of that same method, letting you extend rather than completely replace the inherited behavior. super with no parentheses and no arguments automatically forwards all the arguments the current method received; super() with empty parentheses calls the parent method with no arguments; super(explicit, args) passes exactly the arguments you specify.

🏏

Cricket analogy: A young all-rounder can redefine how they bat compared to their coach's style, and calling super mid-innings is like consulting the coach's original technique before adding their own flair — super() with no args uses the coach's exact method, while super(explicit) borrows only specific tips.

ruby
class Animal
  def initialize(name)
    @name = name
  end

  def speak
    "#{@name} makes a sound"
  end
end

class Dog < Animal
  def initialize(name, breed)
    super(name)          # forwards just `name` to Animal#initialize
    @breed = breed
  end

  def speak
    super + " -- specifically, a bark!"   # extends parent behavior
  end
end

Dog.new("Rex", "Labrador").speak
# => "Rex makes a sound -- specifically, a bark!"

Method resolution order and the ancestor chain

When you call a method on an object, Ruby searches its ancestor chain -- the object's singleton class, its class, any modules mixed into that class (most recently included first), then the superclass, its mixed-in modules, and so on up to Object, Kernel, and BasicObject -- stopping at the first matching method definition it finds. You can inspect this chain directly with SomeClass.ancestors, which is invaluable for debugging why a particular method implementation is (or isn't) being called.

🏏

Cricket analogy: When deciding who bowls a crucial over, a captain checks the specialist bowler first, then all-rounders, then reserves, in order, stopping at the first available option — mirroring Ruby's method lookup through singleton class, class, mixed-in modules, then superclass up to Object.

ruby
Dog.ancestors
# => [Dog, Animal, Object, Kernel, BasicObject]

Dog.superclass   # => Animal
Dog.new("Rex", "Lab").is_a?(Animal)   # => true

Ruby's single inheritance is deliberately simpler than C++'s multiple inheritance, avoiding the classic 'diamond problem' ambiguity of which parent's method wins. Instead, Ruby achieves similar code-sharing power through modules mixed into the ancestor chain with include, which slot in predictably between a class and its superclass without introducing the diamond ambiguity.

Forgetting to call super inside an overridden initialize means the parent class's setup logic never runs, which can leave inherited instance variables uninitialized. This is a very common source of subtle bugs when adding a subclass to an existing hierarchy -- always consider whether the parent's initialize needs to run before or after your own setup code.

Class hierarchies and is-a relationships

Inheritance models an 'is-a' relationship: a Dog is an Animal, so it makes sense for Dog to inherit Animal's shared behavior while adding or specializing its own. is_a? and kind_of? (synonyms) check whether an object's class or any ancestor matches the given class or module, while instance_of? checks only the exact class, ignoring the hierarchy -- an important distinction when writing type checks or case/when dispatch based on class.

🏏

Cricket analogy: A fast bowler is-a bowler, so it makes sense for a fast bowler to inherit a bowler's shared duties while specializing in pace; is_a? would confirm a player is any kind of bowler including spin, while instance_of? checks only if they are exactly a FastBowler.

  • Ruby supports single inheritance via class Subclass < Superclass; every class ultimately inherits from Object/BasicObject.
  • super calls the parent class's version of the current method; bare super forwards all current arguments automatically.
  • Method resolution walks the ancestor chain (singleton class, class, mixed-in modules, superclass, ...) and stops at the first match.
  • SomeClass.ancestors and SomeClass.superclass let you inspect the hierarchy directly for debugging.
  • Forgetting super in an overridden initialize skips the parent's setup logic, often leaving state uninitialized.
  • is_a?/kind_of? check the whole ancestor chain; instance_of? checks only the exact class.

Practice what you learned

Was this page helpful?

Topics covered

#Ruby#RubyStudyNotes#Programming#InheritanceInRuby#Inheritance#Overriding#Methods#Calling#OOP#StudyNotes#SkillVeris