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.
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.
Dog.ancestors
# => [Dog, Animal, Object, Kernel, BasicObject]
Dog.superclass # => Animal
Dog.new("Rex", "Lab").is_a?(Animal) # => trueRuby'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. supercalls the parent class's version of the current method; baresuperforwards all current arguments automatically.- Method resolution walks the ancestor chain (singleton class, class, mixed-in modules, superclass, ...) and stops at the first match.
SomeClass.ancestorsandSomeClass.superclasslet you inspect the hierarchy directly for debugging.- Forgetting
superin an overriddeninitializeskips 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
1. What does bare `super` (no parentheses) do inside an overriding method?
2. How many direct superclasses can a Ruby class have?
3. What is the risk of overriding `initialize` in a subclass without calling `super`?
4. What does `SomeClass.ancestors` return?
5. What is the difference between `is_a?` and `instance_of?`?
Was this page helpful?
You May Also Like
Classes and Objects in Ruby
Learn how Ruby defines classes as blueprints for objects, covering the `class` keyword, `initialize`, instance methods, and how everything in Ruby is an object.
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.
Method Visibility
Learn how Ruby's public, private, and protected keywords control which parts of an object's interface callers can access, and why visibility shapes good API design.
Duck Typing in Ruby
Explore Ruby's duck typing philosophy — objects are defined by the methods they respond to, not by their class — and how it shapes idiomatic, flexible Ruby code.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics