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!

推荐订阅源

DEV Community