SOLID principles in PHP and examples of how to implement them

Details: Written by R. Elizondo; Last Updated: 01 September 2024

The SOLID principles are a set of design principles that promote software development practices that result in maintainable, flexible, and scalable code. Modern PHP Code is implemented based on these.

SOLID is an acronym that stands for:

Single Responsibility Principle (SRP): This principle states that a class should have only one reason to change. It means that a class should have a single responsibility and should be focused on doing one thing well. By separating responsibilities, it becomes easier to understand, test, and maintain individual components.

Open-Closed Principle (OCP): This principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. It means that you should be able to extend the behavior of a system without modifying its existing code. This is usually achieved through the use of abstractions, interfaces, and inheritance.

Liskov Substitution Principle (LSP): This principle states that objects of a superclass should be replaceable with objects of its subclass without affecting the correctness of the program. In other words, if a class is a subtype of another class, it should be able to be used wherever the parent class is expected. Violating this principle can lead to unexpected behavior and bugs.

Interface Segregation Principle (ISP): This principle states that clients should not be forced to depend on interfaces they do not use. It encourages the creation of small, specific interfaces rather than large, general-purpose ones. By doing so, you avoid imposing unnecessary dependencies on clients and ensure that they only depend on the methods they actually need.

Dependency Inversion Principle (DIP): This principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. It promotes loose coupling and allows for more flexibility and easier testing. This principle encourages the use of dependency injection, where dependencies are provided to a class from the outside rather than being instantiated within the class itself.

Single Responsibility Principle (SRP):

- A PHP class should have a single responsibility.
- Avoid creating classes that handle multiple unrelated tasks.
- Split functionality into separate classes, each with a specific responsibility.

Example 1;

class User
{
    private $name;
    private $email;

    public function setName($name)
    {
        $this->name = $name;
    }

    public function setEmail($email)
    {
        $this->email = $email;
    }

    public function save()
    {
        // Code to save the user to the database
    }
}

In this example, the User class has a single responsibility, which is to represent a user and provide methods to set the name and email of the user. The save() method is responsible for saving the user to the database. This adheres to the SRP because the class has only one reason to change, which is if the user representation or the way it is saved needs to be modified.

Example 2:

class EmailSender
{
    public function sendEmail($to, $subject, $body)
    {
        // Code to send an email
    }
}

In this example, the EmailSender class has the responsibility of sending emails. It provides a single method, sendEmail(), which takes the recipient, subject, and body of the email as parameters. This class follows the SRP because its only responsibility is to handle email sending. If there are changes or updates required in the email sending functionality, this class would be the only one affected.

Example 3:

class UserRepository
{
    public function save(User $user)
    {
        // Code to save the user to the database
    }

    public function delete(User $user)
    {
        // Code to delete the user from the database
    }

    public function getById($userId)
    {
        // Code to retrieve a user by ID from the database
    }
}

In this example, the UserRepository class is responsible for data access operations related to users. It provides methods to save, delete, and retrieve users from the database. This class adheres to the SRP because it has a single responsibility of managing database interactions for user entities. If there are changes in how users are stored or retrieved, this class would be the only one affected.

Applying the SRP in PHP leads to classes with well-defined responsibilities, making the code easier to understand, test, and maintain. Each class has a clear purpose and a single reason to change, which improves the overall design and modularity of the application.

Open-Closed Principle (OCP):

- Create abstract classes or interfaces to define the common behavior.
- Implement concrete classes that extend or implement these abstractions.
- Use dependency injection to provide different implementations at runtime.
- Avoid modifying existing code when adding new functionality.

Example 1:

interface Shape
{
    public function calculateArea();
}

class Rectangle implements Shape
{
    private $width;
    private $height;

    public function __construct($width, $height)
    {
        $this->width = $width;
        $this->height = $height;
    }

    public function calculateArea()
    {
        return $this->width * $this->height;
    }
}

class Circle implements Shape
{
    private $radius;

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

    public function calculateArea()
    {
        return pi() * $this->radius * $this->radius;
    }
}

In this example, the Shape interface defines a common contract for calculating the area of different shapes. The Rectangle and Circle classes implement this interface and provide their own implementations of the calculateArea() method. If we want to add more shapes, we can create new classes that implement the Shape interface without modifying the existing code, thus adhering to the OCP.

Example 2:

interface PaymentGateway
{
    public function processPayment($amount);
}

class PayPalGateway implements PaymentGateway
{
    public function processPayment($amount)
    {
        // Code to process payment using PayPal
    }
}

class StripeGateway implements PaymentGateway
{
    public function processPayment($amount)
    {
        // Code to process payment using Stripe
    }
}

In this example, the PaymentGateway interface defines a contract for processing payments. The PayPalGateway and StripeGateway classes implement this interface and provide their own implementations of the processPayment() method. If we want to add more payment gateways, we can create new classes that implement the PaymentGateway interface without modifying the existing code, thus adhering to the OCP.

Example 3:

interface SortAlgorithm
{
    public function sort(array $data);
}

class QuickSort implements SortAlgorithm
{
    public function sort(array $data)
    {
        // Code to perform quick sort on the data
    }
}

class MergeSort implements SortAlgorithm
{
    public function sort(array $data)
    {
        // Code to perform merge sort on the data
    }
}

In this example, the SortAlgorithm interface defines a contract for sorting algorithms. The QuickSort and MergeSort classes implement this interface and provide their own implementations of the sort() method. If we want to add more sorting algorithms, we can create new classes that implement the SortAlgorithm interface without modifying the existing code, thus adhering to the OCP.

Applying the OCP in PHP allows for extending the behavior of a system without modifying existing code. By using abstractions, interfaces, and inheritance, we can create flexible and modular code that can be easily extended with new functionality.

Liskov Substitution Principle (LSP):

- Ensure that subclasses can be used interchangeably with their parent classes.
- Subclasses should not break the contracts defined by their parent classes.
- Override methods in a way that preserves the behavior specified in the superclass.

Example 1:

class Animal
{
    public function makeSound()
    {
        // Common sound behavior for all animals
    }
}

class Dog extends Animal
{
    public function makeSound()
    {
        // Code specific to dogs' sound
    }
}

class Cat extends Animal
{
    public function makeSound()
    {
        // Code specific to cats' sound
    }
}

function makeAnimalSound(Animal $animal)
{
    $animal->makeSound();
}

In this example, the Animal class serves as the parent class for Dog and Cat. Both subclasses inherit the makeSound() method from the Animal class. According to the LSP, we can substitute instances of the parent class (Animal) with instances of its subclasses (Dog or Cat) without affecting the correctness of the program. The makeAnimalSound() function accepts an Animal object as a parameter and calls its makeSound() method, which will behave appropriately for each specific animal subclass

Example 2:

interface FileStorage
{
    public function storeFile($filePath);
    public function getFile($fileId);
}

class LocalFileStorage implements FileStorage
{
    public function storeFile($filePath)
    {
        // Code to store the file locally
    }

    public function getFile($fileId)
    {
        // Code to retrieve a file from local storage
    }
}

class S3FileStorage implements FileStorage
{
    public function storeFile($filePath)
    {
        // Code to store the file on Amazon S3
    }

    public function getFile($fileId)
    {
        // Code to retrieve a file from Amazon S3
    }
}

In this example, the FileStorage interface defines common operations for storing and retrieving files. The LocalFileStorage and S3FileStorage classes implement this interface with their specific implementations. According to the LSP, the S3FileStorage class can be used as a substitute for the LocalFileStorage class, and both should exhibit the same behavior for the common file storage operations.

Example 3:

interface DatabaseConnection
{
    public function connect($host, $username, $password, $database);
    public function query($sql);
}

class MySqlConnection implements DatabaseConnection
{
    public function connect($host, $username, $password, $database)
    {
        // Code to connect to a MySQL database
    }

    public function query($sql)
    {
        // Code to execute a MySQL query
    }
}

class SqliteConnection implements DatabaseConnection
{
    public function connect($host, $username, $password, $database)
    {
        // Code to connect to a SQLite database
    }

    public function query($sql)
    {
        // Code to execute a SQLite query
    }
}

In this example, the DatabaseConnection interface defines methods for connecting to a database and executing queries. The MySqlConnection and SqliteConnection classes implement this interface with their respective database-specific implementations. As per the LSP, the SqliteConnection class can be substituted for the MySqlConnection class, and both should provide the same behavior for connecting to the database and executing queries.

Adhering to the Liskov Substitution Principle allows for substitutability of subclasses with their parent classes. This principle ensures that the behavior defined in the parent class is preserved in its subclasses, allowing for polymorphism and enabling flexible and interchangeable usage of objects.

Interface Segregation Principle (ISP):

- Design small, focused interfaces that only contain the methods required by clients.
- Avoid creating "fat" interfaces that force clients to implement unnecessary methods.
- Use traits or multiple interfaces if a class needs to provide different sets of behavior.

Example 1:

interface UserRegistration
{
    public function registerUser($userData);
}

interface UserAuthentication
{
    public function authenticateUser($username, $password);
}

interface UserProfile
{
    public function getUserProfile($userId);
    public function updateProfile($userId, $userData);
}

class UserSystem implements UserRegistration, UserAuthentication, UserProfile
{
    public function registerUser($userData)
    {
        // Code for user registration
    }

    public function authenticateUser($username, $password)
    {
        // Code for user authentication
    }

    public function getUserProfile($userId)
    {
        // Code for fetching user profile
    }

    public function updateProfile($userId, $userData)
    {
        // Code for updating user profile
    }
}

In this example, we have an interface segregation for user-related operations. The UserRegistration interface is responsible for registering users, the UserAuthentication interface handles user authentication, and the UserProfile interface manages user profiles. The UserSystem class implements all three interfaces, providing the necessary functionalities. By segregating the interfaces, we ensure that clients can depend only on the specific interfaces they need, reducing unnecessary dependencies.

Example 2:

interface Printable
{
    public function printDocument();
}

interface Scanable
{
    public function scanDocument();
}

interface Faxable
{
    public function sendFax();
}

class AllInOnePrinter implements Printable, Scanable, Faxable
{
    public function printDocument()
    {
        // Code for printing a document
    }

    public function scanDocument()
    {
        // Code for scanning a document
    }

    public function sendFax()
    {
        // Code for sending a fax
    }
}

In this example, we have segregated interfaces for different document processing operations. The Printable interface is responsible for printing, the Scanable interface handles scanning, and the Faxable interface manages faxing. The AllInOnePrinter class implements all three interfaces, providing the complete functionality. By segregating the interfaces, clients can depend on the specific interfaces they require, avoiding unnecessary dependencies on functionalities they don't need.

Example 3:

interface PaymentProcessable
{
    public function processPayment($amount);
}

interface Refundable
{
    public function refundPayment($transactionId, $amount);
}

class PayPalGateway implements PaymentProcessable, Refundable
{
    public function processPayment($amount)
    {
        // Code for processing payment through PayPal
    }

    public function refundPayment($transactionId, $amount)
    {
        // Code for refunding payment through PayPal
    }
}

In this example, we have segregated interfaces for payment processing operations. The PaymentProcessable interface is responsible for processing payments, and the Refundable interface manages payment refunds. The PayPalGateway class implements both interfaces, providing the required functionalities. By segregating the interfaces, clients can depend on the specific interfaces they need, allowing for loose coupling and avoiding unnecessary dependencies.

Interface Segregation Principle promotes the creation of small, focused interfaces rather than large, general-purpose ones. By segregating interfaces, we prevent clients from depending on methods they don't use, resulting in more modular, maintainable, and flexible code. Clients can selectively depend on the interfaces that provide the required functionality, reducing coupling and improving code reusability.

Dependency Inversion Principle (DIP):

- Depend on abstractions rather than concrete implementations.
- Use dependency injection to provide dependencies to classes from the outside.
- Favor constructor injection or setter injection over hardcoding dependencies.
- Use inversion of control containers (IoC containers) for managing dependencies.

Example 1:

interface DatabaseConnectionInterface
{
    public function connect();
    public function query($sql);
}

class MySqlConnection implements DatabaseConnectionInterface
{
    public function connect()
    {
        // Code to connect to a MySQL database
    }

    public function query($sql)
    {
        // Code to execute a MySQL query
    }
}

class SqliteConnection implements DatabaseConnectionInterface
{
    public function connect()
    {
        // Code to connect to a SQLite database
    }

    public function query($sql)
    {
        // Code to execute a SQLite query
    }
}

class DatabaseManager
{
    private $connection;

    public function __construct(DatabaseConnectionInterface $connection)
    {
        $this->connection = $connection;
    }

    public function executeQuery($sql)
    {
        $this->connection->connect();
        $this->connection->query($sql);
    }
}

In this example, the DatabaseConnectionInterface defines the contract for database connections, with methods connect() and query(). The MySqlConnection and SqliteConnection classes implement this interface with their respective database-specific functionality. The DatabaseManager class depends on the abstraction (DatabaseConnectionInterface) rather than concrete implementations. This allows the DatabaseManager class to work with any database connection implementation adhering to the interface, enabling flexibility and easy substitution.

Example 2:

interface PaymentGatewayInterface
{
    public function processPayment($amount);
}

class PayPalGateway implements PaymentGatewayInterface
{
    public function processPayment($amount)
    {
        // Code to process payment using PayPal
    }
}

class StripeGateway implements PaymentGatewayInterface
{
    public function processPayment($amount)
    {
        // Code to process payment using Stripe
    }
}

class PaymentProcessor
{
    private $gateway;

    public function __construct(PaymentGatewayInterface $gateway)
    {
        $this->gateway = $gateway;
    }

    public function processPayment($amount)
    {
        $this->gateway->processPayment($amount);
    }
}

In this example, the PaymentGatewayInterface defines the contract for payment gateway implementations, with the processPayment() method. The PayPalGateway and StripeGateway classes implement this interface with their specific payment processing functionality. The PaymentProcessor class depends on the abstraction (PaymentGatewayInterface) rather than concrete implementations. This allows the PaymentProcessor class to work with any payment gateway implementation adhering to the interface, promoting flexibility and easy switching of payment providers.

Example 3:

interface EmailSenderInterface
{
    public function sendEmail($to, $subject, $body);
}

class SmtpEmailSender implements EmailSenderInterface
{
    public function sendEmail($to, $subject, $body)
    {
        // Code to send an email using SMTP
    }
}

class SendGridEmailSender implements EmailSenderInterface
{
    public function sendEmail($to, $subject, $body)
    {
        // Code to send an email using SendGrid
    }
}

class EmailNotifier
{
    private $sender;

    public function __construct(EmailSenderInterface $sender)
    {
        $this->sender = $sender;
    }

    public function sendNotification($recipient, $message)
    {
        $this->sender->sendEmail($recipient, "Notification", $message);
    }
}

In this example, the EmailSenderInterface defines the contract for email sending functionality, with the sendEmail() method. The SmtpEmailSender and SendGridEmailSender classes implement this interface with their respective email sending mechanisms. The EmailNotifier class depends on the abstraction (EmailSenderInterface) rather than concrete implementations, allowing it to work with any email sender implementation adhering to the interface.

Dependency Inversion Principle encourages depending on abstractions rather than concrete implementations. By programming to interfaces, we can easily swap implementations and achieve loose coupling between components. This promotes flexibility, extensibility, and easier maintenance of the codebase.

Review carefully each one of these examples and use them as a reference for your PHP projects. PHP is entering a golden era, and we PHP Developers must adopt best coding practices and adhere to proven software design implementations.

Related Articles

Main Menu

Latest Articles

SOLID principles in PHP and examples of how to implement them

Single Responsibility Principle (SRP):

Open-Closed Principle (OCP):

Liskov Substitution Principle (LSP):

Interface Segregation Principle (ISP):

Dependency Inversion Principle (DIP):