SOLID Principles in Ruby on Rails

Shamila TP — Fri, 29 May 2026 21:02:10 +0000

SOLID Principles in Ruby on Rails

SOLID is not a Rails or Ruby concept. It's a set of five object-oriented design principles that apply to any language/framework.

But Rails makes it surprisingly easy to violate all five of them.

Let's start with

Single Responsibility Principle

It states a class should have only one reason to change.

A classic example is a User model that handles authentication, sends emails, and formats reports. That's three responsibilities. Instead, you'd extract email sending into a Mailer class and reporting into a service object.

class User
  def authenticate
  end

  def send_welcome_email
  end

  def generate_report
  end
end

The Fix

class User < ApplicationRecord
  has_many :orders

  validates :email, presence: true
end

class UserAuthenticationService
  def authenticate
  end
end

class UserMailer < ApplicationMailer
  def send_welcome_email(user)
  end
end

class UserReportService
  def generate_report
  end
end

In Rails, the most common places SRP breaks down are: fat models stuffed with business logic, controllers that do too much, and callbacks that silently trigger side effects.

Open/Closed Principle

A class should be open for extension but closed for modification.

In practice this means: when you need new behaviour, add new code — don't change existing code. This protects stable, tested behaviour from being accidentally broken by new requirements.

class IssueTicketProcessor
  def report_ticket(ticket_type, ticket)
    case ticket_type
    when :hotsos
      p "Processing hotsos ticket : #{ticket}"
    when :know_cross
      p "Processing know_cross ticket : #{ticket}"
    end
  end
end

IssueTicketProcessor.new.report_ticket(:hotsos, "ac not working")

Every time a new issue ticket type comes, this class has to be changed.

The Fix

class TicketIssuer
  def process(ticket)
    raise NotImplementedError
  end
end

class HOTSOSTicketing < TicketIssuer
  def process(ticket)
    puts "Handling HOTSOS ticket: #{ticket}"
  end
end

class KNOWCROSSTicketing < TicketIssuer
  def process(ticket)
    puts "Handling KNOWCROSS ticket: #{ticket}"
  end
end

class IssueTicketProcessor
  def report_ticket(ticket_issuer, ticket)
    ticket_issuer.process(ticket)
  end
end

IssueTicketProcessor.new.report_ticket(
  HOTSOSTicketing.new,
  "TV remote not working"
)

Suppose tomorrow we need to add HoteSoft — no need to change IssueTicketProcessor:

class HoteSoftTicketing < TicketIssuer
  def process(ticket)
    puts "Handling HoteSoft ticket: #{ticket}"
  end
end

Liskov Substitution Principle

Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

This one's about subclasses being replaceable for their base classes without breaking things.

The Problem

class PaymentMethod
  def process(amount)
    raise NotImplementedError
  end
end

class PaypalPayment < PaymentMethod
  def process(amount)
    p "processing paypal payment"
  end
end

class CreditCardPayment < PaymentMethod
  def process(amount, details)       # ← different signature! violates LSP
    p "processing creditcard payment"
  end
end

class PaymentProcessor
  def process(payment_method, amount)
    payment_method.process(amount)
  end
end

payment_method = CreditCardPayment.new
PaymentProcessor.new.process(payment_method, '100')
# Will raise error — CreditCardPayment#process expects 2 arguments

LSP means a subclass should honor the contract of its parent. The fix is to match the parent's method signature:

class CreditCardPayment < PaymentMethod
  def process(amount)
    p "processing creditcard payment"
  end
end

Interface Segregation Principle

No class should be forced to depend on methods it does not use.

Rails-ish Example

Bad

class PaymentGateway
  def charge; end
  def refund; end
  def create_subscription; end
end

Now CashPaymentGateway < PaymentGateway only supports charge, but the parent contract forces it to also carry refund and create_subscription.

The Fix — split into focused modules

module Chargeable
  def charge(amount); end
end

module Refundable
  def refund(amount); end
end

module Subscribable
  def create_subscription(plan); end
end

Since Cash only supports charging, include only Chargeable:

class CashPaymentGateway
  include Chargeable

  def charge(amount)
    puts "Cash payment #{amount}"
  end
end

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Before DIP

class UserRegistration
  def register
    GmailService.new.send_email
  end
end

UserRegistration directly depends on GmailService. If Gmail is replaced with SendGrid, we must modify UserRegistration. This creates tight coupling.

After DIP

class EmailService
  def send_email
    raise NotImplementedError
  end
end

class GmailService < EmailService
  def send_email
    puts "Sending mail via Gmail"
  end
end

class SendGridService < EmailService
  def send_email
    puts "Sending mail via SendGrid"
  end
end

class UserRegistration
  def register(email_service)
    email_service.send_email
  end
end

# Usage:
UserRegistration.new.register(GmailService.new)

Now there's loose coupling and easier testing.

Before DIP

UserRegistration --> GmailService

After DIP

UserRegistration --> EmailService
                         ^
                         |
          ----------------------------
          |                          |
          v                          v
    GmailService            SendGridService

Putting it all together

Principle	Meaning
SRP	One class, one responsibility.
OCP	Extend behavior without modifying existing code.
LSP	Child classes must honor the parent contract.
ISP	Keep interfaces small and focused.
DIP	High-level modules should depend on abstractions.

In a Rails production codebase, here's how they map to common pain points:

Models growing past 300 lines → SRP
Adding a new feature requires touching existing classes → OCP
Subclass behaviour is surprising or inconsistent → LSP
Including a concern drags in methods you don't need → ISP
Tests require heavy mocking of third-party services → DIP

That's the kind of codebase that scales!

Self Referential Associations in Rails - simpler than it sounds

Shamila TP — Mon, 04 May 2026 10:33:39 +0000

Tbh I had no idea this was even a thing until recently. I've been working with Rails for a while now and somehow never came across it.

So let me explain it the way I understood it.

You know how we normally do associations in Rails, User has many Posts, Post belongs to User. Two different models, two different tables. Simple.

But what if a model needs to reference itself? Like same table, same model, but pointing to another record in the same table?

That's all a self referential association is.

The example that made it click for me was Employee and Manager. A manager is just another employee right? So both live in the same employees table.

Let's build it:

rails new self_referential --api
cd self_referential

rails g model Employee name:string manager_id:integer
rails db:migrate

The key column here is manager_id — it just points back to the same table.

Now if you go to Rails console and try alice.manager, you'll get a NoMethodError. Makes sense, we haven't told Rails anything yet.

Here's where you add this to the model:

class Employee < ApplicationRecord
  belongs_to :manager, class_name: "Employee",
                       foreign_key: :manager_id,
                       optional: true

  has_many :subordinates, class_name: "Employee",
                          foreign_key: :manager_id
end

The reason we need class_name and foreign_key, Rails tries to guess the table from the association name. belongs_to :manager makes Rails look for a managers table. That doesn't exist. So we just tell it explicitly, look in employees table, use manager_id column. That's it.

Now this works:

john  = Employee.create!(name: "John")
alice = Employee.create!(name: "Alice", manager: john)
bob   = Employee.create!(name: "Bob",   manager: john)
carol = Employee.create!(name: "Carol", manager: alice)

alice.manager.name             # => "John"
john.subordinates.map(&:name)  # => ["Alice", "Bob"]
carol.manager.name             # => "Alice"
john.manager                   # => nil

One table, one model, navigate relationships in any direction.

Once you get this pattern you'll start seeing it everywhere, comment replies with parent_id, users following other users, categories with subcategories. Same idea every time.

honestly, it sounds scarier than it is. Just a column pointing back to the same table with a bit of guidance for Rails.

DEV Community: Shamila TP

SOLID Principles in Ruby on Rails

SOLID Principles in Ruby on Rails

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Putting it all together

Self Referential Associations in Rails - simpler than it sounds