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!

URL: https://dev.to/shamila_codes/solid-principles-in-ruby-on-rails-87j