SOLID Principles Explained in English: A Guide for Developers

S: Single Responsibility Principle

S: Principio de Responsabilidad Única

A class should have only one reason to change. In plain English: each class or function should do one thing and do it well. When you put too many responsibilities in one place, any change to one responsibility can break another.

class UserManager:
    def create_user(self, username: str, email: str) -> dict:
        # Creates the user in the database
        user = {"username": username, "email": email}
        print(f"Saving user {username} to DB...")  # database logic
        return user

    def send_welcome_email(self, email: str) -> None:
        # Also handles email sending — this is a second responsibility
        print(f"Sending welcome email to {email}...")

    def generate_report(self) -> str:
        # And report generation — a third responsibility
        return "User report: ..."

Problem: UserManager handles user creation, email sending, and report generation. These are three different reasons to change. If the email provider changes, you need to edit this class even though user creation has nothing to do with emails.

class UserRepository:
    def create_user(self, username: str, email: str) -> dict:
        user = {"username": username, "email": email}
        print(f"Saving user {username} to DB...")
        return user


class EmailService:
    def send_welcome_email(self, email: str) -> None:
        print(f"Sending welcome email to {email}...")


class UserReportService:
    def generate_report(self) -> str:
        return "User report: ..."

Now each class has a single responsibility. Changing the email provider only touches EmailService. Changing the report format only touches UserReportService.

O: Open/Closed Principle

O: Principio Abierto/Cerrado

Software entities should be open for extension, but closed for modification. In plain English: you should be able to add new behavior without editing existing code. You extend it, you do not rewrite it.

class DiscountCalculator:
    def calculate(self, order_type: str, price: float) -> float:
        if order_type == "student":
            return price * 0.8  # 20% off
        elif order_type == "employee":
            return price * 0.7  # 30% off
        # Adding "vip" requires editing this function — not closed for modification
        elif order_type == "vip":
            return price * 0.6  # 40% off
        return price

Problem: every time you add a new discount type, you must edit the calculate method. This makes the class fragile and increases the risk of breaking existing logic.

from abc import ABC, abstractmethod


class DiscountStrategy(ABC):
    @abstractmethod
    def apply(self, price: float) -> float:
        pass


class StudentDiscount(DiscountStrategy):
    def apply(self, price: float) -> float:
        return price * 0.8


class EmployeeDiscount(DiscountStrategy):
    def apply(self, price: float) -> float:
        return price * 0.7


class VipDiscount(DiscountStrategy):
    def apply(self, price: float) -> float:
        return price * 0.6


class DiscountCalculator:
    def __init__(self, strategy: DiscountStrategy) -> None:
        self.strategy = strategy

    def calculate(self, price: float) -> float:
        return self.strategy.apply(price)

Now you can add a new discount type by creating a new class. The DiscountCalculator never changes. It is closed for modification but open for extension.

L: Liskov Substitution Principle

L: Principio de Sustitución de Liskov

Objects of a subclass should be replaceable with objects of the parent class without breaking the program. In plain English: if a function works with a Bird, it should still work with any subclass of Bird without unexpected behavior.

class Bird:
    def fly(self) -> str:
        return "I am flying!"


class Penguin(Bird):
    def fly(self) -> str:
        # Penguins cannot fly — this breaks the contract defined by Bird
        raise NotImplementedError("Penguins cannot fly")


def make_bird_fly(bird: Bird) -> str:
    return bird.fly()  # This will crash if called with a Penguin

Problem: Penguin is a Bird, but you cannot substitute a Penguin where a Bird is expected. Calling make_bird_fly(Penguin()) raises an error. The subclass breaks the contract.

from abc import ABC, abstractmethod


class Bird(ABC):
    @abstractmethod
    def move(self) -> str:
        pass


class Sparrow(Bird):
    def move(self) -> str:
        return "I am flying!"


class Penguin(Bird):
    def move(self) -> str:
        return "I am swimming!"


def make_bird_move(bird: Bird) -> str:
    return bird.move()  # Works with any Bird subclass, no surprises

Now Penguin and Sparrow both implement move(), but each in their own way. You can safely substitute any Bird subclass without breaking the program.

I: Interface Segregation Principle

I: Principio de Segregación de Interfaces

Clients should not be forced to depend on interfaces they do not use. In plain English: do not create one giant interface that forces all implementors to define methods they do not need. Split it into smaller, focused interfaces.

from abc import ABC, abstractmethod


class Worker(ABC):
    @abstractmethod
    def work(self) -> None:
        pass

    @abstractmethod
    def eat_lunch(self) -> None:
        pass

    @abstractmethod
    def attend_meeting(self) -> None:
        pass


class Robot(Worker):
    def work(self) -> None:
        print("Robot is working")

    def eat_lunch(self) -> None:
        # Robots do not eat — forced to implement a method that makes no sense
        raise NotImplementedError("Robots do not eat")

    def attend_meeting(self) -> None:
        raise NotImplementedError("Robots do not attend meetings")

Problem: Robot is forced to implement eat_lunch and attend_meeting even though those concepts do not apply. The interface is doing too much.

from abc import ABC, abstractmethod


class Workable(ABC):
    @abstractmethod
    def work(self) -> None:
        pass


class Feedable(ABC):
    @abstractmethod
    def eat_lunch(self) -> None:
        pass


class Attendable(ABC):
    @abstractmethod
    def attend_meeting(self) -> None:
        pass


class HumanWorker(Workable, Feedable, Attendable):
    def work(self) -> None:
        print("Human is working")

    def eat_lunch(self) -> None:
        print("Human is eating lunch")

    def attend_meeting(self) -> None:
        print("Human is attending the meeting")


class Robot(Workable):
    def work(self) -> None:
        print("Robot is working")
    # No eat_lunch, no attend_meeting — only what it actually needs

Now Robot only implements Workable. HumanWorker implements all three. Each class only depends on the interfaces it actually uses.

D: Dependency Inversion Principle

D: Principio de Inversión de Dependencias

High-level modules should not depend on low-level modules. Both should depend on abstractions. In plain English: your business logic should not care which specific database or email service you are using. It should talk to an interface, not a concrete implementation.

class MySQLDatabase:
    def save(self, data: dict) -> None:
        print(f"Saving {data} to MySQL...")


class UserService:
    def __init__(self) -> None:
        # Hard-coded dependency on MySQL — cannot switch without editing this class
        self.db = MySQLDatabase()

    def create_user(self, username: str) -> None:
        self.db.save({"username": username})

Problem: UserService is tightly coupled to MySQLDatabase. If you want to switch to PostgreSQL or use a mock in tests, you have to edit UserService. The high-level module depends on the low-level one.

from abc import ABC, abstractmethod


class Database(ABC):
    @abstractmethod
    def save(self, data: dict) -> None:
        pass


class MySQLDatabase(Database):
    def save(self, data: dict) -> None:
        print(f"Saving {data} to MySQL...")


class PostgreSQLDatabase(Database):
    def save(self, data: dict) -> None:
        print(f"Saving {data} to PostgreSQL...")


class UserService:
    def __init__(self, db: Database) -> None:
        # Depends on the abstraction, not the concrete class
        self.db = db

    def create_user(self, username: str) -> None:
        self.db.save({"username": username})


# Usage: inject whichever implementation you want
service = UserService(db=MySQLDatabase())
test_service = UserService(db=PostgreSQLDatabase())

Now UserService depends on the Database abstraction. You can inject any database that implements that interface, including a mock in tests. The business logic stays unchanged.

How to use SOLID terms in code reviews and PRs

Cómo usar los términos SOLID en code reviews y PRs

Once you know the vocabulary, you can use it precisely in English code reviews. Here are the most common patterns: