Understanding SOLID Principles in Laravel Applications

Miguel Lopez — Tue, 18 Feb 2025 15:41:23 +0000

Understanding SOLID Principles in Laravel Applications

The SOLID principles are a cornerstone of clean and maintainable software design. These principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—help developers build systems that are scalable, testable, and easy to maintain. In this article, we’ll explore each principle in the context of Laravel, providing practical examples along the way.

1. Single Responsibility Principle (SRP)

A class should have one and only one reason to change.

In Laravel, it’s common to see controllers doing too much: handling requests, processing business logic, and interacting with models. This violates SRP. Let’s fix this.

Anti-Pattern

class UserController extends Controller
{
    public function store(Request $request)
    {
        $validated = $request->validate([
            'name' => 'required',
            'email' => 'required|email',
            'password' => 'required|min:8',
        ]);

        $user = new User();
        $user->name = $validated['name'];
        $user->email = $validated['email'];
        $user->password = bcrypt($validated['password']);
        $user->save();

        return response()->json(['message' => 'User created successfully']);
    }
}

Refactored Code

Here, we delegate validation and user creation to separate classes:

class UserController extends Controller
{
    public function store(CreateUserRequest $request, UserService $userService)
    {
        $userService->create($request->validated());
        return response()->json(['message' => 'User created successfully']);
    }
}

// CreateUserRequest.php
class CreateUserRequest extends FormRequest
{
    public function rules()
    {
        return [
            'name' => 'required',
            'email' => 'required|email',
            'password' => 'required|min:8',
        ];
    }
}

// UserService.php
class UserService
{
    public function create(array $data)
    {
        $data['password'] = bcrypt($data['password']);
        return User::create($data);
    }
}

The controller now adheres to SRP by delegating responsibilities.

2. Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

Imagine you’re building a report generator. Initially, you only need to generate PDF reports, but later, you’re asked to add CSV and Excel support. Let’s design this with OCP in mind.

Implementation

Define a contract for report generation:

interface ReportGenerator
{
    public function generate(array $data): string;
}

Create implementations for different formats:

class PdfReportGenerator implements ReportGenerator
{
    public function generate(array $data): string
    {
        // Use a library like dompdf
        return 'PDF report content';
    }
}

class CsvReportGenerator implements ReportGenerator
{
    public function generate(array $data): string
    {
        // Generate CSV content
        return 'CSV report content';
    }
}

Use dependency injection to remain open to new formats:

class ReportService
{
    private ReportGenerator $reportGenerator;

    public function __construct(ReportGenerator $reportGenerator)
    {
        $this->reportGenerator = $reportGenerator;
    }

    public function generateReport(array $data): string
    {
        return $this->reportGenerator->generate($data);
    }
}

By injecting a new implementation of ReportGenerator, you can extend functionality without modifying existing code.

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types.

In Laravel, this principle often applies when extending base classes or implementing interfaces. For example, let’s ensure our payment methods adhere to LSP.

Implementation

Define a payment interface:

interface PaymentMethod
{
    public function charge(float $amount): bool;
}

Implement specific payment methods:

class StripePayment implements PaymentMethod
{
    public function charge(float $amount): bool
    {
        // Call Stripe API
        return true;
    }
}

class PayPalPayment implements PaymentMethod
{
    public function charge(float $amount): bool
    {
        // Call PayPal API
        return true;
    }
}

Use the base type in your service:

class PaymentService
{
    private PaymentMethod $paymentMethod;

    public function __construct(PaymentMethod $paymentMethod)
    {
        $this->paymentMethod = $paymentMethod;
    }

    public function processPayment(float $amount)
    {
        $this->paymentMethod->charge($amount);
    }
}

Substituting StripePayment with PayPalPayment works seamlessly without altering the PaymentService logic.

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they do not use.

In Laravel, using large interfaces can be tempting. Let’s see how to refine them.

Anti-Pattern

interface CrudOperations
{
    public function create(array $data);
    public function read(int $id);
    public function update(int $id, array $data);
    public function delete(int $id);
}

What if some entities don’t support all CRUD operations? For example, logs might not be updated or deleted.

Refactored Code

Split the interface into smaller contracts:

interface Creatable
{
    public function create(array $data);
}

interface Readable
{
    public function read(int $id);
}

Now implement only the relevant interfaces:

class LogService implements Readable, Creatable
{
    public function create(array $data)
    {
        // Create log
    }

    public function read(int $id)
    {
        // Read log
    }
}

This ensures that classes depend only on the methods they actually use.

5. Dependency Inversion Principle (DIP)

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

In Laravel, this is often achieved using dependency injection and service containers.

Anti-Pattern

class NotificationService
{
    public function sendEmail(string $to, string $message)
    {
        // Send email logic
    }
}

The NotificationService depends directly on email implementation.

Refactored Code

Create an abstraction:

interface NotificationChannel
{
    public function send(string $to, string $message);
}

Implement multiple channels:

class EmailChannel implements NotificationChannel
{
    public function send(string $to, string $message)
    {
        // Send email logic
    }
}

class SmsChannel implements NotificationChannel
{
    public function send(string $to, string $message)
    {
        // Send SMS logic
    }
}

Inject the abstraction:

class NotificationService
{
    private NotificationChannel $channel;

    public function __construct(NotificationChannel $channel)
    {
        $this->channel = $channel;
    }

    public function notify(string $to, string $message)
    {
        $this->channel->send($to, $message);
    }
}

Now, swapping the notification channel requires no changes to the NotificationService logic.

Conclusion

Applying the SOLID principles to your Laravel applications enhances their structure and maintainability. By designing classes and interfaces thoughtfully, you can create systems that are easier to test, extend, and debug. Embrace these principles, and watch your codebase flourish!

DEV Community: Miguel Lopez

Understanding SOLID Principles in Laravel Applications

Understanding SOLID Principles in Laravel Applications

1. Single Responsibility Principle (SRP)

Anti-Pattern

Refactored Code

2. Open/Closed Principle (OCP)

Implementation

3. Liskov Substitution Principle (LSP)

Implementation

4. Interface Segregation Principle (ISP)

Anti-Pattern

Refactored Code

5. Dependency Inversion Principle (DIP)

Anti-Pattern

Refactored Code

Conclusion