Single Responsibility Principle: Each class should have one responsibility, so move business logic to service classes, use form requests for validation, and handle side effects via events or jobs. 2. Open/Closed Principle: Extend functionality without modifying existing code by using interfaces and dependency injection, such as binding different payment gateways in Laravel’s service container. 3. Liskov Substitution Principle: Ensure child classes maintain the behavioral contract of their parents, avoiding parameter or behavior inconsistencies in overridden methods. 4. Interface Segregation Principle: Create small, focused interfaces like UserFinder and UserUpdater so clients only depend on methods they use, improving modularity. 5. Dependency Inversion Principle: Depend on abstractions by injecting interfaces into high-level modules, allowing flexible binding of implementations via Laravel’s IoC container. Applying these principles in Laravel enhances maintainability, scalability, and testability by promoting separation of concerns and reducing coupling, ultimately preventing controllers and models from becoming monolithic.

SOLID principles are fundamental object-oriented design concepts that help create maintainable, scalable, and testable code. Laravel, being a modern PHP framework built on Symfony components, provides excellent support for implementing these principles. Here's how you can apply each SOLID principle in a Laravel project.

1. Single Responsibility Principle (SRP)

A class should have only one reason to change.

In Laravel, it’s common to see bloated controllers or models doing too much — handling HTTP logic, business logic, database queries, and even sending emails.

How to apply SRP:

• Move business logic out of controllers and models.
  • Use service classes for business logic.
  • Use form request classes for validation.
  • Use events/listeners or jobs for side effects (e.g., sending emails).

Example:

// app/Services/UserRegistrationService.php
class UserRegistrationService
{
    public function register(array $data): User
    {
        $user = User::create($data);
        event(new UserRegistered($user));
        return $user;
    }
}

Then in your controller:

public function store(UserRegistrationRequest $request, UserRegistrationService $service)
{
    $user = $service->register($request->validated());
    return redirect()->route('users.show', $user);
}

This keeps the controller lightweight and delegates responsibility appropriately.

2. Open/Closed Principle (OCP)

Classes should be open for extension, but closed for modification.

This means you should be able to add new functionality without changing existing code.

How to apply OCP in Laravel:

• Use interfaces and dependency injection.
• Leverage Laravel’s service container to bind implementations.

Example:

// Define an interface
interface PaymentGateway
{
    public function charge(float $amount): bool;
}

// Implement for Stripe
class StripePayment implements PaymentGateway { /* ... */ }

// Implement for PayPal
class PayPalPayment implements PaymentGateway { /* ... */ }

Bind in a service provider:

$this->app->bind(PaymentGateway::class, StripePayment::class);

Now you can switch implementations without changing the consuming class:

class CheckoutController
{
    public function __construct(protected PaymentGateway $gateway) {}

    public function pay(Request $request)
    {
        $this->gateway->charge($request->amount);
        // No code change needed if you switch to PayPal later
    }
}

You can extend functionality by adding new gateways, not modifying existing ones.

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types.

If you’re using inheritance (e.g., extending classes), ensure child classes don’t break the expected behavior of the parent.

How to follow LSP in Laravel:

• Avoid overriding methods in a way that changes their contract.
• Don’t weaken preconditions or strengthen postconditions in child classes.

Example: If you have a base NotificationSender class, make sure all children (e.g., EmailSender, SmsSender) behave predictably when send() is called.

Avoid:

class SmsSender extends NotificationSender
{
    public function send($message, $email) // expects email, but we're sending SMS?
    {
        // Invalid parameter usage — violates LSP
    }
}

Instead, design interfaces that are behaviorally consistent.

4. Interface Segregation Principle (ISP)

Clients shouldn’t be forced to depend on interfaces they don’t use.

Instead of large, generic interfaces, create smaller, specific ones.

How to apply ISP in Laravel:

• Don’t create one massive repository interface with every method.
• Split interfaces by use case.

Example:

interface UserFinder
{
    public function findById(int $id): ?User;
    public function findByEmail(string $email): ?User;
}

interface UserUpdater
{
    public function update(User $user, array $data): bool;
}

Now a service that only needs to find users depends only on UserFinder, not on update methods it doesn’t use.

You can still have a class implement both:

class EloquentUserRepository implements UserFinder, UserUpdater
{
    // Implement both
}

But consumers only depend on what they need.

5. Dependency Inversion Principle (DIP)

Depend on abstractions, not on concretions.

High-level modules (like controllers or services) should not depend directly on low-level details (like Eloquent models or specific APIs).

How to apply DIP in Laravel:

• Use interfaces and Laravel’s IoC container.
• Inject dependencies instead of instantiating them.

Example:

class UserController extends Controller
{
    public function __construct(protected UserFinder $finder) {}

    public function show($id)
    {
        $user = $this->finder->findById($id);
        return view('users.show', compact('user'));
    }
}

Bind the implementation:

// AppServiceProvider.php
public function register()
{
    $this->app->bind(UserFinder::class, EloquentUserRepository::class);
}

Now the controller doesn’t care how the user is found — only that it can be found.

Bonus Tips for Laravel

• Use Actions or Tasks: For complex operations, consider using single-action classes (e.g., CreateOrderAction) to keep things SRP-compliant.
• Leverage Jobs and Listeners: Offload side effects (e.g., notifications, logging) to queued jobs or event listeners.
• Repositories Services: Use repositories to abstract data access, and services to orchestrate logic.
• Avoid Facades in Business Logic: Prefer dependency injection over facades for testability and clarity.

Final Thoughts

Applying SOLID in Laravel isn’t about strict rules — it’s about writing code that’s easier to test, change, and scale. Laravel’s architecture (service container, contracts, events, jobs) makes it natural to follow these principles if you structure your app thoughtfully.

Start small: clean up controllers, extract logic into services, use interfaces, and let the service container do the rest.

Basically, just don’t let Eloquent models or controllers become dumping grounds for everything.

The above is the detailed content of How to implement the SOLID principles in a Laravel project?. For more information, please follow other related articles on the PHP Chinese website!