Implementing SOLID Principles in a Rails Application

When building a Rails application, it’s easy to let the code grow into a tangled mess. The SOLID principles, a set of five object-oriented design guidelines, help keep your codebase clean, maintainable, and scalable. Let’s break them down with practical examples in Rails.

1. Single Responsibility Principle (SRP)

A class should have only one reason to change.

The Problem:

Imagine you have a User model that not only handles database interactions but also sends emails and manages authentication. This makes the class bloated and hard to maintain.

The Solution:

Extract concerns into separate classes:

class UserMailer < ApplicationMailer
  def welcome_email(user)
    @user = user
    mail(to: @user.email, subject: 'Welcome!')
  end
end

class UserAuthenticator
  def self.authenticate(email, password)
    user = User.find_by(email: email)
    user&.authenticate(password)
  end
end

Now, User only deals with data persistence, while UserMailer handles emails and UserAuthenticator manages authentication.

2. Open/Closed Principle (OCP)

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

The Problem:

You have a PaymentProcessor class, and every time you add a new payment method, you modify it.

The Solution:

Use polymorphism to allow new payment methods without modifying existing code:

class PaymentMethod
  def process(amount)
    raise NotImplementedError, "Subclasses must implement the process method"
  end
end

class CreditCardPayment < PaymentMethod
  def process(amount)
    puts "Processing credit card payment of $#{amount}"
  end
end

class PayPalPayment < PaymentMethod
  def process(amount)
    puts "Processing PayPal payment of $#{amount}"
  end
end

class PaymentProcessor
  def self.process(payment_method, amount)
    raise ArgumentError, "Invalid payment method" unless payment_method.is_a?(PaymentMethod)

    payment_method.process(amount)
  end
end

credit_card = CreditCardPayment.new
paypal = PayPalPayment.new

PaymentProcessor.process(credit_card, 100) # ✅ Works
PaymentProcessor.process(paypal, 200)      # ✅ Works

Analysis of Implementation

Base Class (PaymentMethod):

• The PaymentMethod class serves as an abstract base class with a method process. It raises a NotImplementedError, enforcing that any subclass must implement this method.

Subclasses (CreditCardPayment and PayPalPayment):

• Both CreditCardPayment and PayPalPayment are concrete implementations of PaymentMethod. Each subclass implements the process method, providing specific behavior for processing payments.

PaymentProcessor Class:

• The PaymentProcessor class is responsible for processing payments. It checks if the provided payment method is a valid instance of PaymentMethod and then calls the appropriate process method.
• The design allows for new payment methods to be added (e.g., BitcoinPayment, ApplePayPayment, etc.) without modifying the existing code in the PaymentProcessor. You would simply create a new subclass of PaymentMethod and implement the process method.

Conclusion

Implementation correctly follows the Open/Closed Principle because:

• Extensibility: You can easily add new payment methods by creating new subclasses without modifying existing classes.
• Encapsulation: The logic for each payment method is encapsulated within its respective class, keeping the code clean and maintainable.

Example of Extending Functionality

If you wanted to add a new payment method, such as a bank transfer, you could do so like this

class BankTransferPayment < PaymentMethod
  def process(amount)
    puts "Processing bank transfer payment of $#{amount}"
  end
end

Now, you can process bank transfer payments without changing any existing code in the PaymentProcessor or other payment classes.

3. Liskov Substitution Principle (LSP)

Subtypes should be replaceable without breaking functionality.

The Problem:

You have a Bird superclass with a fly method, but not all birds can fly.

The Solution:

Refactor into separate classes:

class Bird
  def make_sound
    raise NotImplementedError
  end
end

module Flying
  def fly
    puts 'I can fly!'
  end
end

class FlyingBird < Bird
  include Flying
end

class Penguin < Bird
  def swim
    puts 'I swim instead of flying!'
  end
end

Now, Penguin doesn't inherit a fly method it can't use, maintaining LSP.

4. Interface Segregation Principle (ISP)

A class should not be forced to implement methods it does not use.

The Problem:

A ReportGenerator class requires methods for both PDF and CSV generation, but not all reports need both.

The Solution:

Split responsibilities into separate modules:

module PdfExportable
  def export_to_pdf
    puts 'Exporting to PDF'
  end
end

module CsvExportable
  def export_to_csv
    puts 'Exporting to CSV'
  end
end

class PdfReport
  include PdfExportable
end

class CsvReport
  include CsvExportable
end

Now, each class only includes the functionality it needs.
Neither class is forced to implement methods it doesn’t need. PdfReport doesn't have to implement CSV exporting, and CsvReport doesn't have to implement PDF exporting.

5. Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations.

The Problem:

A NotificationService directly instantiates an EmailNotifier, making it hard to switch to SMS notifications.

The Solution:

Use dependency injection:

class NotificationService
  def initialize(notifier)
    @notifier = notifier
  end
  def send_notification(message)
    @notifier.notify(message)
  end
end

class EmailNotifier
  def notify(message)
    puts "Sending Email: #{message}"
  end
end

class SmsNotifier
  def notify(message)
    puts "Sending SMS: #{message}"
  end
end

Now, NotificationService can work with any notifier without modifications:

service = NotificationService.new(SmsNotifier.new)
service.send_notification('Hello!')

Analysis of Implementation

High-Level Module:

• The NotificationService class is a high-level module that is responsible for sending notifications. It does not know about the specific details of how notifications are sent (whether by email, SMS, etc.).

Low-Level Modules:

• The EmailNotifier and SmsNotifier classes are low-level modules that implement the actual notification logic.

Dependency Injection:

• The NotificationService class depends on an abstraction (notifier) rather than a concrete implementation. This is achieved through dependency injection, where an instance of a notifier (either EmailNotifier or SmsNotifier) is passed to the NotificationService during initialization.

Flexibility and Extensibility:

• You can easily add new notifier types (e.g., PushNotifier, SlackNotifier, etc.) without modifying the NotificationService class. You would simply create a new notifier class that implements the notify method.

Conclusion

By applying the SOLID principles in your Rails app, you create a more scalable, maintainable, and testable codebase. Start small — refactor a bloated class, use dependency injection, or introduce interfaces. Over time, these principles will become second nature, leading to cleaner, more robust applications.

Happy coding! 🚀