SOLID – 5 Design Principles for Building Better Software

Good software is not defined solely by whether it performs its intended functions correctly. Its architecture, maintainability, scalability, and ability to adapt to change are equally important.

Software architecture can be compared to the foundation of a house: the stronger the foundation, the more stable the building and the easier it is to expand in the future. Conversely, a system built on a poorly designed architecture can quickly become difficult to maintain as requirements change or the application grows.

In object-oriented programming (OOP), one of the fundamental concepts that helps us design better systems is SOLID – a set of five object-oriented design principles that make software easier to understand, maintain, extend, and reuse.

1. How Did SOLID Come About?

Object-Oriented Programming (OOP) is one of the most widely used programming paradigms. OOP provides several important characteristics that allow us to model real-world objects and problems, including:

• Abstraction: Modeling objects by focusing on their essential characteristics and behaviors.
• Encapsulation: Bundling data and related behaviors into a single object while controlling how external components access them.
• Inheritance: Allowing a class to inherit and extend attributes and behaviors from another class.
• Polymorphism: Allowing the same action to be performed in different ways depending on the specific object involved.

These characteristics allow developers to build programs capable of solving a wide range of real-world problems. However, knowing how to use OOP does not necessarily mean knowing how to design a good OOP system.

The key challenge lies in how we organize and combine the characteristics of OOP to create a system with a reasonable structure, that is easy to change and has minimal unnecessary dependencies.

This is one of the main goals of SOLID.

2. What Is SOLID?

SOLID is an acronym for five object-oriented design principles. These principles help developers create code that is clear, understandable, maintainable, and extensible.

The five principles are:

• S – Single Responsibility Principle (SRP)
• O – Open/Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

Let's take a closer look at each principle through practical examples.

3. Single Responsibility Principle – SRP

Definition

A class should have only one responsibility.

SRP is the first principle of SOLID. A class should not be responsible for too many unrelated functions. When a class has multiple responsibilities, it can quickly become difficult to understand, test, and maintain.

In real-world software development, requirements change frequently. Customers may request new features, modify business rules, or change how the system operates. Therefore, organizing code clearly and separating responsibilities appropriately are extremely important.

Example

Suppose a software company has three positions:

• Developer – develops software.
• Tester – tests software.
• Salesman – sells software.

An initial design might look like this:

class Employee
{
    string position;

    function developSoftware(){};
    function testSoftware(){};
    function saleSoftware(){};
}

This design has a problem because Employee is responsible for too many things.

A Developer does not need testSoftware() or saleSoftware(). A Tester does not need developSoftware(). If the system later adds more positions such as HR, Project Manager, Accountant, and so on, the Employee class will continue to grow.

Furthermore, unrelated methods could be called accidentally, increasing the risk of errors.

Applying the Single Responsibility Principle

Instead of putting all functions into a single class, we can create an abstract Employee class with a common working() behavior:

abstract class Employee
{
    public abstract function working();
}

Then we create specific classes:

class Developer extends Employee
{
    public function working()
    {
        // Develop software
    }
}

class Tester extends Employee
{
    public function working()
    {
        // Test software
    }
}

class Salesman extends Employee
{
    public function working()
    {
        // Sell software
    }
}

Each class now focuses on one specific responsibility, making the code easier to understand, test, and extend.

4. Open/Closed Principle – OCP

Definition

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

OCP is the second principle of SOLID.

When we need to add new functionality, instead of continuously modifying existing code, we should design the system so that it can be extended by adding new components while minimizing changes to existing, stable components.

This is particularly useful in systems that frequently need new features.

Example

Suppose we have a class responsible for establishing database connections:

class ConnectionManager
{
    public function doConnection(Object $connection)
    {
        if ($connection instanceof SqlServer) {
            // Connect with SqlServer
        } elseif ($connection instanceof MySql) {
            // Connect with MySql
        }
    }
}

Initially, the system supports only SQL Server and MySQL.

Later, a new requirement appears: the system must also support Oracle and other database management systems.

With the design above, we would have to continuously add more else if branches:

if (...)
{
    ...
}
elseif (...)
{
    ...
}
elseif (...)
{
    ...
}

As the number of supported databases increases, ConnectionManager will become increasingly complex and difficult to maintain.

Solution

We can separate the parts that are likely to change from the parts that are stable by introducing an abstraction.

First, create a base Connection class:

abstract class Connection
{
    public abstract function doConnect();
}

Specific database implementations can then inherit from this class:

class SqlServer extends Connection
{
    public function doConnect()
    {
        // Connect with SqlServer
    }
}

class MySql extends Connection
{
    public function doConnect()
    {
        // Connect with MySql
    }
}

ConnectionManager only needs to work with the abstraction:

class ConnectionManager
{
    public function doConnection(Connection $connection)
    {
        $connection->doConnect();
    }
}

When we need to support a new database, we only have to create a new class that extends Connection, instead of modifying ConnectionManager.

This is the essence of the Open/Closed Principle: open for extension, closed for modification.

5. Liskov Substitution Principle – LSP

Definition

Objects of a subclass should be replaceable with objects of the superclass without breaking the correctness of the program.

LSP is the third principle of SOLID.

In other words, when a class inherits from another class, the subclass should comply with the behaviors and expectations established by the superclass.

Example

Let's return to the Employee example.

Suppose the company requires all official employees to check in every morning. We therefore add the following method to Employee:

checkAttendance()

However, the company also employs temporary cleaning staff. These employees do not have official employee IDs and are therefore not required to check in.

If we create:

class CleanerStaff extends Employee

then CleanerStaff automatically inherits checkAttendance().

This creates a design problem: CleanerStaff does not fully satisfy the behaviors expected of an Employee.

Therefore, having CleanerStaff inherit from Employee can result in a violation of the Liskov Substitution Principle.

Possible solution

One solution is to move checkAttendance() into a separate interface.

Only employee types that are actually required to check in should implement this interface.

This prevents us from forcing a class to inherit behaviors that do not apply to it.

6. Interface Segregation Principle – ISP

Definition

Instead of using one large interface, prefer multiple smaller interfaces, each serving a specific purpose.

ISP is the fourth principle of SOLID.

Imagine that we have an interface containing 100 methods. Every class implementing this interface would be required to implement all 100 methods, even if it only actually needs a few of them.

This creates unnecessary code and increases unwanted dependencies.

Example

Suppose we have the following interface:

interface Animal
{
    void eat();
    void run();
    void fly();
}

If both Dog and Snake implement this interface, we immediately encounter a problem:

• A Dog can eat() and run(), but cannot fly().
• A Snake can eat(), but it does not make sense to force it to implement run() or fly().

Instead of creating one large interface, we can split it into smaller interfaces:

interface Animal
{
    void eat();
}

interface RunnableAnimal extends Animal
{
    void run();
}

interface FlyableAnimal extends Animal
{
    void fly();
}

Each class only needs to implement the interfaces containing the behaviors it actually requires.

As a result, the code becomes clearer, dependencies are reduced, and the system becomes easier to manage.

7. Dependency Inversion Principle – DIP

Definition

DIP consists of two main principles:

1. High-level modules should not depend directly on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details; details should depend on abstractions.

In simple terms, components within a system should communicate through abstractions or interfaces rather than depending directly on a specific implementation.

Why Is Dependency Inversion Important?

Abstractions generally represent stable characteristics that are less likely to change. Concrete implementations, on the other hand, may change depending on the requirements of the system.

When a high-level module directly depends on a concrete implementation, any change to that implementation may require changes to the high-level module as well.

If both depend on an abstraction instead, implementations can be replaced much more flexibly.

Real-World Example

Consider a computer's storage device.

A motherboard does not need to know whether you are using:

• an SSD;
• an HDD;
• or another specific type of storage device.

What matters is that the device follows a supported interface standard, such as SATA.

In this example:

• SATA plays a role similar to an abstraction/interface.
• SSD or HDD represents a concrete implementation.

The same concept applies to software development.

For example, instead of having a high-level module depend directly on MySQL, we can create an abstraction:

interface DataAccess
{
    public function save();
    public function get();
}

Then, specific implementations can implement this interface:

class MySqlDataAccess implements DataAccess
{
    public function save()
    {
        // Save data to MySQL
    }

    public function get()
    {
        // Get data from MySQL
    }
}

If we later need to switch to MongoDB or another database management system, we can create a new implementation without having to make extensive changes to the logic that depends on the abstraction.

This is one of the key benefits of Dependency Inversion: it reduces direct dependencies between modules and makes the system more flexible when requirements change.

8. Conclusion

SOLID is a set of five important principles for object-oriented software design. The goal is not to turn every piece of code into a complex system filled with classes and interfaces. Instead, SOLID helps us organize system components in a more logical and maintainable way.

The five principles can be summarized as follows:

What Are the Benefits of SOLID?

1. Clearer and More Understandable Code

SOLID encourages developers to divide responsibilities appropriately, making code easier to read and understand, especially in team-based development environments.

2. Easier to Change and Extend

When modules are designed independently and unnecessary dependencies are minimized, adding or changing requirements is less likely to create a chain reaction throughout the entire system.

3. Better Reusability

Classes and modules with clearly defined responsibilities, flexible designs, and dependencies on abstractions have greater potential for reuse across different parts of a system.

4. Easier Maintenance and Testing

A system designed according to SOLID principles typically consists of smaller, less dependent components with clearly defined responsibilities. This makes testing, debugging, and maintenance easier.

SOLID is not a set of rules that must be applied blindly in every situation. Its real value lies in helping developers develop better design thinking: knowing how to separate responsibilities, manage dependencies, and build systems that can adapt to change.

When applied appropriately and in the right context, SOLID becomes an important foundation for building software systems that are easy to understand, maintain, extend, and capable of evolving over the long term.