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!