The SOLID Principles: Fundamentals of Object-Oriented Programming

Posted by

  



The SOLID principles are a set of fundamental guidelines for designing robust, scalable, and maintainable software. These principles, introduced by Robert C. Martin (known as "Uncle Bob"), are particularly useful in object-oriented programming (OOP). The correct application of these principles helps reduce code complexity, improve reusability, and make software easier to maintain over time.

In this article, we will explore each principle in detail, first illustrating an example of incorrect code and then its correct application in JavaScript.

🔗 Do you like Techelopment? Check out the website for all the details!


1. Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have only one reason to change, that is, it should be responsible for only one aspect of the software. In other words, a class should have only one well-defined purpose.

If a class takes on multiple responsibilities, it becomes harder to test, maintain, and change. This leads to rigid and brittle code, where a change to one part of the class can unexpectedly affect other parts of the class. Separating responsibilities helps reduce the risk of bugs and improves code clarity and organization.

Incorrect code (SRP violation)

class MySQLDatabase {
    save(data) {
        console.log("Saving data to MySQL database: ", data);
    }
}

class UserService {
    constructor() {
        this.database = new MySQLDatabase();
    }
    saveUser(user) {
        this.database.save(user);
    }
}


class User {
    constructor(name, email) {
        this.name = name;
        this.email = email;
    }

    save() {
        console.log(`Saving user ${this.name} to database.`);
    }

    sendEmail(message) {
        console.log(`Sending email to ${this.email}: ${message}`);
    }
}

Problem: The User class has multiple responsibilities: it handles both user data and email persistence and sending. If we change the logic for saving or sending emails, we will have to modify this class, violating SRP.

Correct code (SRP application)

class User {
    constructor(name, email) {
        this.name = name;
        this.email = email;
    }
}

class UserRepository {
    save(user) {
        console.log(`Saving user ${user.name} to database.`);
    }
}

class EmailService {
    sendEmail(user, message) {
        console.log(`Sending email to ${user.email}: ${message}`);
    }
}

Solution: We have separated the responsibilities between three classes: User, UserRepository and EmailService. Now we can change the persistence method or sending emails without changing the user logic.


2. Open/Closed Principle (OCP)

The Open/Closed Principle states that a software entity (class, module, function, etc.) should be open to extension but closed to modification. This means that we should be able to add new functionality without having to modify existing code, thus avoiding introducing new bugs into already tested and working code.

This principle is especially useful when the software grows over time and we need to add new functionality without risking breaking existing functionality. The best way to respect OCP is to use inheritance or polymorphism to extend the behavior of classes without directly modifying them.

Incorrect code (OCP violation)


class Discount {
    calculate(amount, type) {
        if (type === "percentage") {
        return amount - (amount * 10) / 100;
        } else if (type === "fixed") {
        return amount - 20;
        }
        return amount;
    }
}

Problem: If we want to add a new discount type, we have to modify the Discount class, violating OCP.

Correct code (OCP application)


class Discount {
    calculate(amount) {
        return amount;
    }
}

class PercentageDiscount extends Discount {
    constructor(percent) {
        super();
        this.percent = percent;
    }
    calculate(amount) {
        return amount - (amount * this.percent) / 100;
    }
}

class FixedDiscount extends Discount {
    constructor(amountOff) {
        super();
        this.amountOff = amountOff;
    }
    calculate(amount) {
        return amount - this.amountOff;
    }
}

Solution: Now we can add new discount types without changing Discount, respecting OCP.


3. Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that derived classes should be able to replace their base classes without altering the behavior of the program. If a subclass violates this principle, it means that it is not really a valid replacement for the parent class and may cause code to break.

A typical LSP violation occurs when a subclass modifies or removes inherited behavior, causing parts of the code that expect the original behavior to fail.

Incorrect code (LSP violation)


class Rectangle {
    constructor(width, height) {
        this.width = width;
        this.height = height;
    }
    getArea() {
        return this.width * this.height;
    }
}

class Square extends Rectangle {
    constructor(size) {
        super(size, size);
    }
    setWidth(width) {
        this.width = width;
        this.height = width;
    }
    setHeight(height) {
        this.width = height;
        this.height = height;
    }
}

Problem: Square changes the behavior of Rectangle in an unexpected way. If a function expects a Rectangle, it may behave incorrectly with a Square.

Correct code (LSP application)


class Shape {
    getArea() {
        throw new Error("Method not implemented");
    }
}

class Rectangle extends Shape {
    constructor(width, height) {
        super();
        this.width = width;
        this.height = height;
    }
    getArea() {
        return this.width * this.height;
    }
}

class Square extends Shape {
    constructor(size) {
        super();
        this.size = size;
    }
    getArea() {
        return this.size * this.size;
    }
}

Solution: We separate Rectangle and Square, making them both derive from a common abstraction (Shape) without violating LSP.


4. Interface Segregation Principle (ISP)

The Interface Segregation Principle states that no client should be forced to depend on methods it does not use. In other words, it is better to have multiple specific interfaces than to have a single general interface with irrelevant methods for all classes that implement it.

This principle helps to avoid creating interfaces that are too large and complex, improving maintainability and code clarity. If a class is forced to implement irrelevant methods, it may be a sign that the interface is poorly designed.

Incorrect code (ISP violation)

class Worker {
    work() {
        console.log("Working...");
    }

    eat() {
        console.log("Eating...");
    }
}

class Robot extends Worker {
    eat() {
        throw new Error("Robots don't eat!");
    }
}

class Human extends Worker {
    eat() {
        console.log("Human is eating...");
    }
}

Problem: The Worker class has a single method eat() that is relevant only for human workers, but not for robots. Forcing Robot to implement a method that doesn't make sense for its logic is a violation of ISP.

Correct code (ISP application)

class Workable {
    work() {
        console.log("Working...");
    }
}

class Eatable {
    eat() {
        console.log("Eating...");
    }
}

class Robot extends Workable {
    work() {
        console.log("Robot is working...");
    }
}

class Human extends Workable {
    constructor() {
        super();
        this.eater = new Eatable();
    }

    work() {
        console.log("Human is working...");
    }

    eat() {
        this.eater.eat();
    }
}

Solution: We have separated the responsibilities into two distinct interfaces (Workable and Eatable). Now, the Robot class implements only Workable, without being forced to implement useless methods like eat(). On the other hand, the Human class can implement both interfaces, benefiting from the separation of responsibilities.


5. Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that high-level classes should not directly depend on low-level classes, but both should depend on abstractions (interfaces or abstract classes). Furthermore, abstractions should not depend on concrete details, but the other way around.

Following this principle allows you to reduce tight coupling between classes, making your code more flexible and testable. If a class directly depends on a concrete implementation, any change to that implementation may require changes to the dependent class as well.

Incorrect code (DIP violation)


class MySQLDatabase {
    save(data) {
        console.log("Saving data to MySQL database: ", data);
    }
}

class UserService {
    constructor() {
        this.database = new MySQLDatabase();
    }
    saveUser(user) {
        this.database.save(user);
    }
}

Problem: UserService depends directly on the concrete class MySQLDatabase. If we wanted to change database, we would have to modify UserService, violating DIP.

Correct code (DIP application)


class Database {
    save(data) {
        throw new Error("Method not implemented");
    }
}

class MySQLDatabase extends Database {
    save(data) {
        console.log("Saving data to MySQL database: ", data);
    }
}

class UserService {
    constructor(database) {
        this.database = database;
    }
    saveUser(user) {
        this.database.save(user);
    }
}

const database = new MySQLDatabase();
const userService = new UserService(database);
userService.saveUser({ name: "John Doe" });

Solution: UserService now depends on an abstraction (Database) and not on a concrete implementation. This allows you to replace MySQLDatabase with another implementation (e.g. PostgreSQLDatabase) without changing UserService.


Conclusion

SOLID principles are essential for writing clean, flexible, and maintainable code. Applying them correctly helps reduce class coupling, improve testability, and make software more adaptable to change.

Following these principles allows developers to avoid many of the common pitfalls of object-oriented programming, improving code quality and longevity.

If you want to further improve your understanding of SOLID, try refactoring existing code using these principles and see how it improves the readability and modularity of your software.

 

Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment