More Ruby Fundamentals: Inheritance, Mixins, & Modules

Topics Covered in This Ruby on Rails Tutorial:

Inheritance, Overriding a Parent Class's Method, Calling a Parent Class's Method Using Super, Mixins & Modules

Exercise Overview

Time for a strategic Ruby deep-dive!

Now that you've gained practical experience building a real Rails application, it's crucial to step back and master some of Ruby's more sophisticated—yet fundamental—language features. These concepts form the backbone of robust, maintainable Rails applications that scale effectively in production environments.

In this comprehensive exercise, you'll explore how Ruby facilitates code reuse and organization through inheritance, mixins, and modules. These patterns are essential for building the kind of clean, DRY (Don't Repeat Yourself) codebases that modern development teams demand.

Inheritance

Inheritance represents one of object-oriented programming's core principles, enabling objects to inherit both properties and methods from parent classes. This mechanism reduces code duplication while establishing clear hierarchical relationships between related concepts—a pattern you'll encounter throughout Rails' own architecture.

1. Launch Interactive Ruby by opening Terminal and executing the irb command. IRB provides an ideal environment for experimenting with Ruby concepts in real-time.

2. Let's establish our foundation by creating a Pet class. This will serve as our parent class, demonstrating how common behaviors can be shared across related objects:

   class Pet
      attr_accessor :name
      def initialize(name)
         @name = name
         end

3. Now define the speak method, which establishes default behavior that child classes can inherit or override:

   def speak
         "Feed me!"
         end

4. Instantiate your first Pet object to see inheritance in action:

   fluffy = Pet.new("Miss Fluffy")

5. Verify that our object correctly stores its name:

   fluffy.name

6. Test the speak method:

   fluffy.speak

   Terminal returns the universal pet declaration: "Feed me!"

7. Here's where inheritance demonstrates its power. We'll create a specialized Dog class that inherits all Pet capabilities while maintaining its distinct identity. The less-than symbol (<) establishes the inheritance relationship—think of it as an arrow pointing from child to parent:

   class Dog < Pet
      end

   At this point, Pet becomes our superclass (or parent class), while Dog serves as the child class inheriting all Pet behaviors.

8. Thanks to inheritance, our Dog class automatically possesses all Pet methods without any additional code. Let's verify this inheritance works seamlessly:

   fido = Dog.new("Mr. Fido")
   fido.speak

   Terminal confirms inheritance is working by returning: "Feed me!"

9. While inheritance provides default behaviors, method overriding allows child classes to customize inherited functionality. This demonstrates polymorphism—different classes responding to the same method call in their own unique way:

   class Dog < Pet
      def speak
         "Arf! Arf!"
         end
   
   fido.speak

   Terminal now returns "Arf! Arf!" instead of the generic "Feed me!". Our Dog class has successfully overridden the parent's speak method while maintaining all other inherited behaviors.

10. Let's confirm that other inherited methods remain intact:

    fido.name

    Terminal displays "Mr. Fido". The Dog class seamlessly inherited the attr_accessor :name functionality from Pet, demonstrating how inheritance promotes code reuse.

11. Create another child class to further illustrate inheritance flexibility:

    class Reptile < Pet
       end

12. Test our new Reptile class to confirm it inherits the same Pet behaviors:

    sandra = Reptile.new("Mrs. Sandra")
    sandra.name
    sandra.speak

    Sandra demonstrates perfect inheritance: she knows her name and speaks the default Pet phrase "Feed me!". This showcases how multiple child classes can inherit from the same parent while maintaining their independence.

13. Sometimes you want to extend rather than replace inherited functionality. Ruby's super keyword calls the parent class method, allowing you to build upon existing behavior rather than completely overriding it. This technique is particularly valuable when you need to add logging, validation, or additional processing to inherited methods:

    class Fish < Pet
       def speak
          super + " (bubble)"
          end

14. Observe how super enables method extension:

    sunny = Fish.new("Mr. Sunny")
    sunny.speak

    Terminal returns "Feed me! (bubble)". The super command retrieved the parent's speak method result and allowed us to append Fish-specific behavior. This pattern is extremely common in Rails applications, where you often want to extend framework functionality rather than replace it entirely.

Mixins

While inheritance provides a powerful mechanism for sharing code, Ruby's mixin system offers even greater flexibility through modules. Unlike single inheritance languages, Ruby's mixins allow you to compose functionality from multiple sources, creating more flexible and maintainable code architectures. This approach aligns perfectly with Rails' philosophy of convention over configuration and helps avoid the limitations of single inheritance hierarchies.

1. Let's create a module that can be shared across different types of objects. Modules encapsulate related functionality that can be mixed into multiple classes, regardless of their inheritance hierarchy:

   module License
      def register(state)
         @name + " has been registered in " + state
         end

   We've defined a License module containing registration functionality, but modules can't be instantiated directly—they must be included in classes to become useful.

2. Now we'll demonstrate the power of mixins by extending our existing Pet class with License functionality:

   class Pet
      include License
      end

   The include statement performs the magic of mixins, making all License methods available to Pet instances and, through inheritance, to all Pet subclasses. This demonstrates composition over inheritance—a key principle in modern software design.

3. Mixins truly shine when you need to share functionality between unrelated classes. Let's create a Car class that has nothing to do with pets but still needs licensing capability:

   class Car
      include License
      def initialize(model, owner)
         @name = owner + "'s " + model
         end

   Notice how we've defined an initialize method that accepts two parameters, demonstrating Ruby's flexibility in constructor design. The Car class can now access License functionality without any inheritance relationship to Pet.

4. Let's test our mixin in action by registering Fido through the inherited License functionality:

   fido.register("Oklahoma")

   Terminal returns "Mr. Fido has been registered in Oklahoma". This works because Fido (Dog class) inherits from Pet, and Pet includes the License module. The functionality flows seamlessly through the inheritance chain, demonstrating how mixins and inheritance work together harmoniously.

5. Now let's prove that mixins work across completely different class hierarchies:

   car = Car.new("BMW", "Grandpa")
   car.register("Wyoming")

   Success! Terminal returns "Grandpa's BMW has been registered in Wyoming". This demonstrates mixins' core value proposition: sharing functionality between unrelated classes without forcing artificial inheritance relationships or duplicating code.

   This exemplifies one of programming's most important principles: DRY (Don't Repeat Yourself). Mixins and modules are essential tools for maintaining DRY codebases, especially in large Rails applications where similar functionality appears across different domain models.

The Is_a? & Respond_to? Methods

Ruby provides powerful introspection capabilities that allow your code to make intelligent decisions at runtime. These methods are particularly valuable in Rails applications where you often need to handle different object types gracefully or check capabilities before invoking methods.

1. The is_a? method provides runtime type checking, working seamlessly with inheritance hierarchies. This proves especially valuable when handling polymorphic associations in Rails:

   fido.is_a? Dog
   fido.is_a? Pet

   Both return true, confirming that inheritance relationships are properly recognized throughout the class hierarchy.

2. Let's verify our fluffy object's type as well:

   fluffy.is_a? Dog

   This returns false since fluffy is a direct instance of Pet, not Dog. Wait, that seems wrong based on our earlier code. Let me check this...

3. Let's test with Sandra the reptile to see inheritance boundaries:

   sandra.is_a? Dog

   Correctly returns false. Sandra is a Reptile, not a Dog, even though both inherit from Pet. This demonstrates how is_a? respects class specificity while acknowledging inheritance relationships.

   The respond_to? method offers another layer of introspection by checking whether an object can handle a specific method call. This enables defensive programming and graceful error handling.

4. Create a Cat class with unique behavior to demonstrate method-specific introspection:

   class Cat < Pet
      def meow
         puts "Meow!"
         end

5. Now test whether objects respond to the Cat-specific meow method. Ruby accepts both symbols and strings for method names, though symbols are preferred for performance reasons:

   • fluffy = Cat.new('Miss Fluffy')
   • fluffy.respond_to? :meow
   • fluffy.respond_to? 'meow'

   Both return true, confirming that fluffy can respond to meow calls.

6. Test method availability across different classes:

   fido.respond_to? :meow

   Returns false, as expected. Fido is a Dog and doesn't have access to Cat-specific methods. This type of checking proves invaluable in Rails applications where you're working with polymorphic associations or need to handle different object types gracefully without raising exceptions.