Skip to content

Instantly share code, notes, and snippets.

@edipofederle
Created October 9, 2025 13:30
Show Gist options
  • Select an option

  • Save edipofederle/a7395436b1459c6a7d3adf3bc3fbe0a5 to your computer and use it in GitHub Desktop.

Select an option

Save edipofederle/a7395436b1459c6a7d3adf3bc3fbe0a5 to your computer and use it in GitHub Desktop.
Write
Sign up
Sign in
Ruby Inheritance and Object Hierarchy
Betsy Sallee
Betsy Sallee
Follow
4 min read
·
May 20, 2018
132
1
You know the old saying: Everything in Ruby is an Object. But what does that mean? Where do these Objects come from, and why do they behave the way they do?
Objects come from classes, which you can think of as the blueprints for individual objects — they define the behavior of each and every instance of that particular class. But in order to fully understand the Object-Oriented nature of the Ruby language, it’s essential that you understand object hierarchy: namely, that every instance of a particular class inherits properties and behaviors from its ancestors. For instance, we can create a class Person:
…and then create a class Programmer that inherits behavior from Person:
Now, we can create an instance of Programmer that has access to both the methods inside Person and inside Programmer.
2.3.3 :061 > betsy = Programmer.new("Betsy", 28)
=> #<Programmer:0x007fb58f00d0d8 @name="Betsy", @age=28>
2.3.3 :062 > betsy.say_hello
Hello, my name is Betsy.
=> nil
2.3.3 :063 > betsy.tell_us_what_you_love
I love programming!
=> nil
But things get really interesting when we call .ancestors on Programmer:
2.3.3 :064 > Programmer.ancestors
=> [Programmer, Person, Object, Kernel, BasicObject]
Here, we can see that instances of the class Programmer not only inherit behavior from the class Person, but they also inherit behavior from the class Object, the module Kernel, and the class BasicObject. Each of these ancestors builds on the “DNA” — namely, the properties and behaviors — of those that come before it. But what specific functionality do BasicObject, Kernel, and Object offer? Let’s dive in.
BasicObject
Instances of BasicObject, which is the most primitive Ruby class, come with very little functionality. In fact, BasicObject has only thirteen methods: #new, #!, #!=, #==, #__id__, #__send__, #equal?, #instance_eval, #instance_exec, #method_missing, #singleton_method_added, #singleton_method_removed, and #singleton_method_undefined. As such, it’s not possible to create an instance of BasicObject in IRB because BasicObject doesn’t have an #inspect method.
2.3.3 :001 > a_basic_object = BasicObject.new
(Object doesn't support #inspect)
=>
So what’s the point of BasicObject? According to The Well-Grounded Rubyist by David A. Black, “BasicObject enables you to create objects that do nothing, which means you can teach them to do everything — without worrying about clashing with existing methods.” This means that BasicObject offers you a blank slate — a way for you to create objects without having to contend with pre-determined behavior. It’s unlikely that you’ll need to instantiate instances of BasicObject very often, but when that time comes, the sky is the limit.
Kernel
The Object class owes much of its functionality to the Kernel module, which it includes. Kernel contains 66 method definitions, such as #puts, #gets, #chomp, and #exit, and these methods are available to every Ruby object. In fact, these methods are so commonplace that they can almost be mistaken for language keywords. It’s important to note, however, that many of the Kernel methods are private methods, so they cannot be called with a receiver. You can see this in action if you try to call #puts on an instance of Array:
2.3.3 :065 > array = ["ruby", "class", "hierarchy", "is", "fascinating"]
=> ["ruby", "class", "hierarchy", "is", "fascinating"]
2.3.3 :066 > array.puts
NoMethodError: private method `puts' called for ["ruby", "class", "hierarchy", "is", "fascinating"]:Array
The above example illustrates a crucial distinction: while #puts is available to any Ruby object, it can only be called on whatever self is in the current context.
Object
Every object in Ruby — with the exception of instances of BasicObject — is an ancestor of Object, and Main is an instance of the Object class itself. Object has 49 methods, in addition to the methods it includes through Kernel. These methods include #class, #is_a, #methods, #send, and #object_id. Additionally, when you define a top-level method — meaning a method that is not inside a class or a module — you’re creating a private instance method of Object. Because every object in Ruby inherits from the Object class, these private instance methods can be called anywhere in your program, so long as they’re called on self without an explicit receiver.
Get Betsy Sallee’s stories in your inbox
Join Medium for free to get updates from this writer.
Subscribe
It’s interesting to note that Object is an instance of Ruby’s built-in class called Class. Because Class is a subclass of Object, Object is essentially a subclass of itself.
2.3.3 :001 > Object.class
=> Class
2.3.3 :002 > Class.ancestors
=> [Class, Module, Object, Kernel, BasicObject]
Have I blown your mind yet?
Conclusion
It’s true what they say: Everything in Ruby is an Object, and every object in Ruby inherits behavior from the class Object (which includes Kernel), as well as from the class BasicObject, which is the base of the Ruby family tree. These Ruby ancestors give us access to methods such as #new, #!, and #== (from BasicObject); #puts, #gets, and #chomp (from Kernel, which is included by Object); and #class, #is_a, and #send (from Object itself). It’s easy to take these methods for granted and assume that they are Ruby keywords, but this assumption is inaccurate. So, the next time you use these methods, take a minute to honor the Ruby ancestors: Ruby wouldn’t be what it is without them.
Programming
Ruby
Object Oriented
Flatiron School
Coding
132
1
Betsy Sallee
Written by Betsy Sallee
274 followers
·
22 following
betsysallee.com
Follow
Responses (1)
Write a response
What are your thoughts?
Cancel
Respond
Izak T
Izak T
Apr 4, 2019
it can only be called on whatever self is in the current context.
could you please explain this more?
Reply
More from Betsy Sallee
Function Borrowing in JavaScript
Betsy Sallee
Betsy Sallee
Function Borrowing in JavaScript
When we create JavaScript objects, we typically associate them with certain behavior. Consider the below example:
Jun 10, 2018
758
6
The Difference Between .sort and .sort_by in Ruby
Betsy Sallee
Betsy Sallee
The Difference Between .sort and .sort_by in Ruby
I just completed my second week of the Software Engineering Immersive at Flatiron School, and I’m going to unpack the difference between…
May 6, 2018
270
1
A 10 Step Guide to Flexbox
Betsy Sallee
Betsy Sallee
A 10 Step Guide to Flexbox
Responsive design got you down? Tired of guessing about Flexbox properties? Follow these simple steps and you’ll never have to copy and…
Jan 22, 2019
513
1
Demystifying By Value vs. By Reference
Betsy Sallee
Betsy Sallee
Demystifying By Value vs. By Reference
If you’re new to JavaScript, it can be tempting to fasten your seat belt, step on the gas, and careen through the language as quickly as…
Aug 15, 2018
51
1
See all from Betsy Sallee
Recommended from Medium
Rails API Best Practices That’ll Save Your Sanity in 2025
Slim Ben Nasrallah
Slim Ben Nasrallah
Rails API Best Practices That’ll Save Your Sanity in 2025
Remember when building APIs felt like magic? “Just slap some JSON on it and call it a day!” Yeah, those were simpler times. Now we live in…
Sep 27
5
Ruby 3.3 is Here: What Every Rails Developer Should Know 🚀
Ravi Prakash
Ravi Prakash
Ruby 3.3 is Here: What Every Rails Developer Should Know 🚀
If you’re a Ruby on Rails developer like me, you know the joy of working with a language that’s elegant, expressive, and…
6d ago
9
1
🔥SOLID: Liskov Substitution Principle (LSP) in a Rails Project
Stackademic
In
Stackademic
by
Adarsh Mishra
🔥SOLID: Liskov Substitution Principle (LSP) in a Rails Project
We’ve already hung out with the first two SOLID principles, now it’s time to meet the smooth talker of the group — the Liskov Substitution…
Aug 12
Singleton, Unique Jobs, Concurrency — Ruby on Rails
Level Up Coding
In
Level Up Coding
by
Panos Matsinopoulos
Singleton, Unique Jobs, Concurrency — Ruby on Rails
Hints and Suggestions About Sidekiq Jobs
Apr 14
9
1
The Senior Dev’s Guide to Effective Database Indexing in Rails
Sajjad Umar
Sajjad Umar
The Senior Dev’s Guide to Effective Database Indexing in Rails
Senior Dev’s Guide to Effective Database Indexing in Rails — by Sajjad Umar
Oct 1
4
The Power of Encapsulation in Ruby: Understanding Object Attributes and Access Control
Aditya Bhuyan
Aditya Bhuyan
The Power of Encapsulation in Ruby: Understanding Object Attributes and Access Control
This topic gets right to the heart of object-oriented programming principles in Ruby!
Sep 17
See more recommendations
Help
Status
About
Careers
Press
Blog
Privacy
Rules
Terms
Text to speech
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment