SOLID Design Principles - Quick Revision

Introduction to SOLID Principles

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. These principles were introduced by Robert C. Martin and have become fundamental guidelines for good object-oriented design.

Single Responsibility Principle (SRP)

The Single Responsibility Principle states that "A class should have one, and only one, reason to change." This means that a class should have a single, well-defined purpose.

Example: End-of-Day Process

Instead of having a single class handle multiple responsibilities:

class DownloadPhase {
    function execute() { /* logic to download file */ }
}

class ParsePhase {
    function execute() { /* logic to process file */ }
}

class SendFilePhase {
    function execute() { /* logic to send file */ }
}

class EODProcess {
    function run() {
        DownloadPhase download = new DownloadPhase();
        ParsePhase parse = new ParsePhase();
        SendFilePhase sendFile = new SendFilePhase();

        download.execute();
        parse.execute();
        sendFile.execute();
    }
}

We can split it into separate classes:

class DownloadPhase:
    function execute()

class ParsePhase:
    function execute()

class SendFilePhase:
    function execute()

class EODProcess:
    function run():
        DownloadPhase.execute()
        ParsePhase.execute()
        SendFilePhase.execute()

This approach makes each class focused on a single task, improving maintainability and testability.

Open/Closed Principle (OCP)

The Open/Closed Principle states that "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

Example: Shape Interface

interface Shape:
    function area()

class Circle implements Shape:
    function area()

class Rectangle implements Shape:
    function area()

class AreaCalculator:
    function calculateTotalArea(shapes):
        total = 0
        for each shape in shapes:
            total += shape.area()
        return total

This design allows new shapes to be added without modifying existing code. The AreaCalculator class remains unchanged when new shapes are introduced.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that "Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program."

Example: Vehicle Class Hierarchy

class Vehicle {
    function startEngine() {}
    function accelerate() {}
}

class PetrolCar extends Vehicle {
    function startEngine() { /* Petrol car engine start logic */ }
    function accelerate() { /* Petrol car acceleration logic */ }
}

class ElectricCar extends Vehicle {
    function startEngine() { /* Electric car engine start logic */ }
    function accelerate() { /* Electric car acceleration logic */ }
}

function testDrive(Vehicle vehicle) {
    vehicle.startEngine();
    vehicle.accelerate();
}

Here, any subclass of Vehicle can be used in the testDrive function without breaking the program's behavior.

Interface Segregation Principle (ISP)

The Interface Segregation Principle states that "Clients should not be forced to depend upon interfaces they do not use."

Example: Printer Interface

interface Printer {
    function print();
}

interface Scanner {
    function scan();
}

interface Fax {
    function fax();
}

class SimplePrinter implements Printer {
    function print() { /* print logic */ }
}

class AllInOnePrinter implements Printer, Scanner, Fax {
    function print() { /* print logic */ }
    function scan() { /* scan logic */ }
    function fax() { /* fax logic */ }
}

This design allows classes to implement only the interfaces they need, avoiding unnecessary dependencies.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that "High-level modules should not depend on low-level modules. Both should depend on abstractions."

Example: File Parser

interface Parser {
    function parse(String data);
}

class XMLParser implements Parser {
    function parse(String data) { /* XML parsing logic */ }
}

class JSONParser implements Parser {
    function parse(String data) { /* JSON parsing logic */ }
}

class DataProcessor {
    private Parser parser;

    DataProcessor(Parser parser) {
        this.parser = parser;
    }

    function process(String data) {
        var parsedData = parser.parse(data);
        // Further processing of parsedData
    }
}

In this design, the high-level DataProcessor depends on the Parser abstraction, not on concrete implementations, allowing for flexibility and easier testing.

Advantages of SOLID Principles

• Clean Code: SOLID principles promote clean and standardized code.
• Maintainability: Code becomes more manageable and easier to maintain.
• Scalability: Easier to refactor or change code as requirements evolve.
• Reduced Redundancy: SOLID principles help avoid redundant code.
• Testability: Code can be more easily unit tested.
• Readability: SOLID principles make the code easier to read and understand.
• Independence: Code becomes more independent by reducing dependencies.
• Reusability: Components become more reusable across different parts of the application.

Frequently Asked Questions