Solid like a rock! SOLID Principles: A simple and easy explanation

SOLID is a coding standard that every developer should understand clearly when building software in a proper, maintainable way. Promoted by Robert C. Martin and used across the object-oriented design spectrum, these five principles – when applied consistently – make your code more extendable, logical, and easier to read.

When a developer builds software without following a disciplined design approach, the code can become inflexible and brittle. Small changes can introduce bugs across unrelated parts of the system. SOLID is the answer to that problem – not a theoretical exercise, but a practical discipline that produces code you can actually work with. It takes time to internalise, but once you do, you will find these principles embedded in the architecture of every well-designed system you encounter.

The five SOLID principles form a unified approach to object-oriented design that keeps code clean, extendable, and resilient to change.

The Five Principles at a Glance

Each letter in SOLID maps to a distinct principle. Together they form a coherent framework for writing classes and modules that are easy to test, extend, and maintain. To understand SOLID fully, you need a clear concept of how interfaces work – they are the mechanism behind several of the principles.

S – Single Responsibility Principle

One class should serve one purpose. This does not mean each class can only have one method – it means all methods and properties should work towards the same goal. When a class serves multiple responsibilities, those responsibilities should each live in their own dedicated class.

The OrdersReport class below does three different things: retrieving data from a database, formatting output as HTML, and combining those concerns in a single method. Any one of those concerns could independently force you to change this class – a clear sign it is carrying too much responsibility:

namespace Demo;
use DB;
class OrdersReport
{
    public function getOrdersInfo($startDate, $endDate)
    {
        $orders = $this->queryDBForOrders($startDate, $endDate);
        return $this->format($orders);
    }
    protected function queryDBForOrders($startDate, $endDate)
    {
        return DB::table('orders')
            ->whereBetween('created_at', [$startDate, $endDate])
            ->get();
    }
    protected function format($orders)
    {
        return '<h1>Orders: ' . $orders . '</h1>';
    }
}

The refactored version separates each concern into its own class. The repository handles persistence, the formatter handles output, and the report class simply orchestrates. Now each class has exactly one reason to change:

namespace Report;
use Report\Repositories\OrdersRepository;

class OrdersReport
{
    protected $repo;
    protected $formatter;

    public function __construct(OrdersRepository $repo, OrdersOutPutInterface $formatter)
    {
        $this->repo = $repo;
        $this->formatter = $formatter;
    }

    public function getOrdersInfo($startDate, $endDate)
    {
        $orders = $this->repo->getOrdersWithDate($startDate, $endDate);
        return $this->formatter->output($orders);
    }
}

namespace Report;
interface OrdersOutPutInterface
{
    public function output($orders);
}

namespace Report;
class HtmlOutput implements OrdersOutPutInterface
{
    public function output($orders)
    {
        return '<h1>Orders: ' . $orders . '</h1>';
    }
}

namespace Report\Repositories;
use DB;
class OrdersRepository
{
    public function getOrdersWithDate($startDate, $endDate)
    {
        return DB::table('orders')
            ->whereBetween('created_at', [$startDate, $endDate])
            ->get();
    }
}

O – Open-Closed Principle

Classes, modules, and functions should be extendable without requiring you to change the original code. If you follow this principle consistently, you can modify system behaviour by adding new code – not by editing existing, tested code that already works. The aim is to avoid touching a class that already does its job correctly.

In the example below, adding a new shape like Square forces you to modify the calculate method in CostManager. That breaks the Open-Closed Principle – the class is not closed for modification:

class CostManager
{
    public function calculate($shape)
    {
        $costPerUnit = 1.5;
        if ($shape instanceof Rectangle) {
            $area = $shape->width * $shape->height;
        } else {
            $area = $shape->radius * $shape->radius * pi();
        }
        return $costPerUnit * $area;
    }
}

With the Open-Closed approach, each shape implements its own calculateArea() method via an interface. CostManager never needs to change when a new shape is added:

interface AreaInterface
{
    public function calculateArea();
}

class Rectangle implements AreaInterface
{
    public $width;
    public $height;

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

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

class Circle implements AreaInterface
{
    public $radius;

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

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

class CostManager
{
    public function calculate(AreaInterface $shape)
    {
        $costPerUnit = 1.5;
        return $costPerUnit * $shape->calculateArea();
    }
}

L – Liskov Substitution Principle

The Liskov Substitution Principle was introduced by Barbara Liskov in her 1987 conference keynote and formalised alongside Jeannette Wing in a 1994 paper. It states that any implementation of an abstraction – an interface – should be substitutable in any place that abstraction is accepted. Practically, this means that different classes implementing the same interface should not only accept the same inputs but return the same type of output.

The violation below is subtle but dangerous. Both classes implement the same interface, but DbLessonRepository originally returned an Eloquent Collection – a different type from the plain array returned by FileLessonRepository. Any consumer expecting an array would break silently at runtime:

interface LessonRepositoryInterface
{
    public function getAll();
}

class FileLessonRepository implements LessonRepositoryInterface
{
    public function getAll()
    {
        return [];  // returns array
    }
}

class DbLessonRepository implements LessonRepositoryInterface
{
    public function getAll()
    {
        // Violation: Eloquent Collection, not an array
        // return Lesson::all();

        // Fix: normalise the return type to match the contract
        return Lesson::all()->toArray();
    }
}

Interfaces define the contract. Liskov Substitution ensures every implementation of that contract behaves predictably – consumers should never need to know which concrete class they are working with.

I – Interface Segregation Principle

Break large interfaces into smaller, more focused ones so each client only depends on what it actually needs. The goal is the same as the Single Responsibility Principle – minimise side effects and eliminate unnecessary coupling by keeping each interface narrow and purposeful. Similar to SRP, the Interface Segregation Principle divides the software into multiple independent parts.

In the example below, RobotWorker is forced to implement sleep() even though it has no use for it. That is a clear violation of ISP:

interface WorkerInterface
{
    public function work();
    public function sleep();
}

class HumanWorker implements WorkerInterface
{
    public function work()
    {
        var_dump('works');
    }

    public function sleep()
    {
        var_dump('sleep');
    }
}

class RobotWorker implements WorkerInterface
{
    public function work()
    {
        var_dump('works');
    }

    public function sleep()
    {
        // Not needed -- forced to implement anyway
    }
}

Splitting into two focused interfaces solves it immediately. RobotWorker implements only WorkAbleInterface – the one thing it actually needs:

interface WorkAbleInterface
{
    public function work();
}

interface SleepAbleInterface
{
    public function sleep();
}

class HumanWorker implements WorkAbleInterface, SleepAbleInterface
{
    public function work()
    {
        var_dump('works');
    }

    public function sleep()
    {
        var_dump('sleep');
    }
}

class RobotWorker implements WorkAbleInterface
{
    public function work()
    {
        var_dump('works');
    }
}

D – Dependency Inversion Principle

This principle is frequently confused with dependency injection, but they are not the same. Dependency injection is a technique for supplying dependencies. Dependency Inversion is a design rule about what those dependencies should point at: abstractions, not concrete implementations.

In the violation below, PasswordReminder depends directly on MySQLConnection. Switching to MongoDB would require editing the high-level class, which has nothing to do with the choice of database:

class MySQLConnection
{
    public function connect()
    {
        var_dump('MYSQL Connection');
    }
}

class PasswordReminder
{
    private $dbConnection;

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

By introducing a ConnectionInterface, both the high-level and low-level modules depend on the abstraction. You can now swap MySQLConnection for any other connection class without touching PasswordReminder at all:

interface ConnectionInterface
{
    public function connect();
}

class DbConnection implements ConnectionInterface
{
    public function connect()
    {
        var_dump('MYSQL Connection');
    }
}

class PasswordReminder
{
    private $dbConnection;

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

Applied together, the SOLID principles produce a codebase where each module has a single clear purpose, dependencies point toward abstractions, and new behaviour can be added without touching existing code.

Signs You Are Following SOLID – and Signs You Are Not