Posted inArchitecture Development

SOLID Concept

April 13, 2025No Comments

SOLID Principles Simplified & Explained in Detail

The SOLID principles are a set of five design principles that aim to make software designs more understandable, flexible, and maintainable. These principles are particularly relevant in object-oriented programming and are intended to help developers create systems that are easier to manage and extend over time. This document will delve into each of the SOLID principles, providing detailed explanations and examples to illustrate their importance and application in software development.

S – Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have only one job or responsibility. This principle helps to reduce the complexity of a class and makes it easier to understand and maintain.

Example:

Consider a class that handles both user authentication and user data management. If the authentication logic changes, it could inadvertently affect the data management functionality. By separating these concerns into two distinct classes, each with its own responsibility, we can ensure that changes in one area do not impact the other.

class UserAuthenticator:
    def authenticate(self, username, password):
        # Authentication logic here
        pass

class UserDataManager:
    def save_user_data(self, user_data):
        # Data management logic here
        pass

  • Concept: A class should have only one reason to change (one responsibility).

  • Diagram:

    • Bad: One class handling multiple unrelated jobs. If one job’s requirements change, the whole class might need modification, potentially breaking the other job.

      +--------------------------+
|   UserAuthAndDataMgr     |  <-- Handles too much!
+--------------------------+
| - Authentication Logic   |
| - Data Management Logic  |
+--------------------------+
| + authenticate()         |
| + save_user_data()       |
+--------------------------+
         ^       ^
         |       |
Change in Auth?  Change in Data Mgmt?
(Both impact this single class)

    • Good: Responsibilities are separated into distinct classes. Changes in one area don’t affect the other.

      +---------------------+      +----------------------+
|  UserAuthenticator  |      |   UserDataManager    | <-- Each has one job
+---------------------+      +----------------------+
| - Auth Logic        |      | - Data Mgmt Logic    |
+---------------------+      +----------------------+
| + authenticate()    |      | + save_user_data()   |
+---------------------+      +----------------------+
         ^                             ^
         |                             |
Change in Auth?                 Change in Data Mgmt?
(Impacts only this class)       (Impacts only this class)

O – 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. This means that we should be able to add new functionality without altering existing code, which helps to prevent bugs and maintain stability.

Example:

Using interfaces or abstract classes allows us to extend functionality without modifying existing code. For instance, if we have a payment processing system, we can create new payment methods by implementing a common interface rather than changing the existing payment processing code.

class PaymentProcessor:
    def process_payment(self, payment):
        pass

class CreditCardPayment(PaymentProcessor):
    def process_payment(self, payment):
        # Process credit card payment
        pass

class PayPalPayment(PaymentProcessor):
    def process_payment(self, payment):
        # Process PayPal payment
        pass

  • Concept: Software entities should be open for extension, but closed for modification. Add new functionality without changing existing code.

  • Diagram:

    • Bad (Conceptual): To add a new payment type, you have to modify the existing PaymentProcessor class (e.g., adding an if/else or switch).

      +--------------------------+
|     PaymentProcessor     | <-- Needs modification for new types ❌
+--------------------------+
| + process_payment(type)  |
|   {                      |
|     if (type == 'Credit')|
|     else if (type == 'PayPal')|
|     else if (type == 'NEW_TYPE') // <-- MODIFYING existing code
|   }                      |
+--------------------------+

    • Good: Use an abstraction (interface or abstract class). Add new types by creating new classes that implement/extend the abstraction. The original code doesn’t change.

            +------------------------+
      | <<Interface>>          |
      |   PaymentProcessor     | <-- Closed for modification ✅
      +------------------------+
      | + process_payment()    |
      +------------------------+
              ^      ^      ^
     implements |      |      | implements (New type added via EXTENSION)
     +------------------+   +---------------+   +------------------+
     | CreditCardPayment|   | PayPalPayment |   | NewPaymentMethod | <-- Open for extension ✅
     +------------------+   +---------------+   +------------------+
     | + process_payment|   | + process_pay |   | + process_payment|
     +------------------+   +---------------+   +------------------+

L – Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This principle ensures that a subclass can stand in for its superclass without causing issues.

Example:

If we have a class Bird and a subclass Penguin, which cannot fly, we should not violate the LSP by having a method that assumes all birds can fly. Instead, we can create an interface for flying birds and ensure that only those that can fly implement it.

class Bird:
    def make_sound(self):
        pass

class FlyingBird(Bird):
    def fly(self):
        pass

class Sparrow(FlyingBird):
    def make_sound(self):
        return "Chirp"

class Penguin(Bird):
    def make_sound(self):
        return "Honk"

  • Concept: Subtypes must be substitutable for their base types without altering the correctness of the program.  

    Diagram:

    • Bad: A subclass (Penguin) cannot fulfill the contract of the superclass (Bird) if the superclass assumes capabilities the subclass lacks (like fly()).

      +------------+       Client Code expects a Bird and calls fly()
|    Bird    | <-----------------------+
+------------+                         |
| + fly()    |                         |
+------------+                         |
      ^                                |
inherits|                                |
+------------+                         |
|  Penguin   | ----(Cannot fly!)-----> 💥 Error / Unexpected Behavior
+------------+
| + fly() { // Problematic implementation } |
+------------+

    • Good: Design hierarchies based on actual substitutability. If flying is optional, separate it, perhaps via another abstraction or by not having fly() in the base Bird class if not all birds fly.

      +------------+       Client Code needs a flying bird? Ask for FlyingBird.
|    Bird    | <-----------------------+
+------------+                         |
| +make_sound|                         |
+------------+                         |
  ^       ^                            |
  |       | inherits                   |
  |   +-------------+                  |
  |   | FlyingBird  | -----------------+
  |   +-------------+
  |   | + fly()     |
  |   +-------------+
  |         ^
  | inherits|
  |   +-------------+
  |   |   Sparrow   |
  |   +-------------+
  |   | + fly()     |
  |   +-------------+
  |
inherits|
+------------+
|  Penguin   |  <-- Doesn't inherit FlyingBird. Correctly not substitutable
+------------+      where fly() is expected.
| +make_sound|
+------------+

Why it might be seen as "less correct" or problematic:
      • Implicit Contracts: The “contract” (what methods a Bird is expected to have) is implied by the methods actually present in the base Bird class. You have to look at the Bird implementation to know its contract. If fly was accidentally left in Bird, LSP would be broken.
      • No Enforcement: Python doesn’t force subclasses (Sparrow, Penguin) to actually provide meaningful implementations for methods inherited with pass (like make_sound in the base Bird or fly in FlyingBird). A Sparrow could technically be created without a working fly method, potentially causing errors only when fly is called at runtime.
      • Inheritance for Capability: FlyingBird inherits from Bird. This mixes the “is-a” relationship (FlyingBird is a Bird) with adding a specific capability (fly). While functional, this can sometimes be less clear than explicitly declaring capabilities.
      • Less Robust: The design relies more on developer convention and careful management. It’s easier to accidentally modify the Bird class later and reintroduce an LSP violation.
      Better Approach

      This version clearly defines what capabilities are expected without providing implementation in the base abstract classes, forcing subclasses to provide them.

      Python

      import abc

# --- Define Abstract Base Classes (Contracts) ---

class Bird(abc.ABC):
    """
    Abstract base class for all birds.
    Defines the essential contract for being a bird.
    """
    @abc.abstractmethod
    def make_sound(self):
        """All birds must provide an implementation for making a sound."""
        pass

class Flying(abc.ABC):
    """
    Abstract base class (or Mixin) for flying capability.
    Defines the contract for flying.
    """
    @abc.abstractmethod
    def fly(self):
        """Entities implementing this must provide an implementation for flying."""
        pass

# --- Concrete Implementations ---

class Sparrow(Bird, Flying): # Inherits BOTH contracts
    """
    A Sparrow is a Bird and it implements the Flying capability.
    """
    def make_sound(self):
        # Provides concrete implementation required by Bird
        return "Chirp"

    def fly(self):
        # Provides concrete implementation required by Flying
        print("Sparrow flying high!")

class Penguin(Bird): # Inherits ONLY the Bird contract
    """
    A Penguin is a Bird, but it does NOT implement the Flying capability.
    """
    def make_sound(self):
        # Provides concrete implementation required by Bird
        return "Honk"
    # No fly() method is defined or inherited abstractly without implementation.

# --- How it satisfies LSP ---

def make_bird_speak(bird_instance: Bird):
    """This function expects any object that fulfills the Bird contract."""
    print(f"The bird says: {bird_instance.make_sound()}")

def initiate_flight(flyer: Flying):
    """This function expects any object that fulfills the Flying contract."""
    print("Attempting to initiate flight...")
    flyer.fly()

# --- Usage Examples ---

sparrow = Sparrow()
penguin = Penguin()

print("--- Testing Bird Contract ---")
make_bird_speak(sparrow)  # Works: Sparrow is a Bird, has make_sound()
make_bird_speak(penguin)  # Works: Penguin is a Bird, has make_sound()
# Safe substitution: Both Sparrow and Penguin work where a Bird is expected for make_sound.

print("\n--- Testing Flying Contract ---")
initiate_flight(sparrow) # Works: Sparrow implements Flying, has fly()
# initiate_flight(penguin) # This would cause an ERROR (AttributeError or TypeError depending on checks)
                           # because Penguin does not fulfill the Flying contract.
                           # LSP is maintained because you can't incorrectly substitute Penguin here.

      Explanation of why this is a “correct” example adhering to LSP:

      1. Explicit Contracts (ABCs): Bird and Flying are defined as Abstract Base Classes ( abstract or interface is better choice compared to normal class).  They explicitly state, using @abc.abstractmethod, which methods must be implemented by any concrete subclass. This makes the required capabilities clear.
      2. Clear Separation: The concept of being a Bird (must make_sound) is completely separate from the concept of being able to Fly (must fly).
      3. Composition of Capabilities: Sparrow inherits from both Bird and Flying, fulfilling both contracts by implementing both make_sound and fly.
      4. Limited Inheritance: Penguin inherits only from Bird, fulfilling that contract by implementing make_sound. It does not inherit from Flying, so it has no fly method and no obligation to implement one.
      5. LSP Adherence:
        • You can safely pass either a Sparrow or a Penguin to a function expecting a Bird (like make_bird_speak) because both correctly implement make_sound.
        • You can safely pass a Sparrow to a function expecting a Flying object (like initiate_flight) because it implements fly.
        • You cannot pass a Penguin to initiate_flight. This is correct behavior – the type system (or runtime checks) would prevent this invalid substitution, upholding LSP. The program doesn’t break by trying to make a non-flyer fly.
        • More Robust and Maintainable: The explicit contracts and enforcement make the code safer to modify and extend. If you add a new abstract method to Bird, you immediately know all direct subclasses need updating. This strongly encourages adherence to LSP and OCP (Open/Closed Principle).

      In summary:

      While the first example technically solved the immediate LSP problem by separating fly from Penguin, it did so using implicit contracts and relied on careful implementation. The second example using ABCs is considered more correct in a broader design sense because it uses language features (abc) to create explicit, enforced contracts, leading to clearer, more robust, and more maintainable code that better embodies the principles behind SOLID design. It leaves less room for error or misunderstanding.

I – Interface Segregation Principle (ISP)

The Interface Segregation Principle states that no client should be forced to depend on methods it does not use. This principle encourages the creation of smaller, more specific interfaces rather than large, general-purpose ones.

Example:

Instead of having a large interface for all types of vehicles, we can create smaller interfaces for specific functionalities, such as Drivable, Flyable, and Sailable. This way, a class can implement only the interfaces relevant to its functionality.

class Drivable:
    def drive(self):
        pass

class Flyable:
    def fly(self):
        pass

class Car(Drivable):
    def drive(self):
        # Driving logic here
        pass

class Airplane(Flyable):
    def fly(self):
        # Flying logic here
        pass

  • Concept: Clients should not be forced to depend on interfaces they do not use. Prefer smaller, specific interfaces over large, general ones.

  • Diagram:

    • Bad: A large “fat” interface forces implementing classes (like Car) to deal with methods they don’t need (like fly()). Clients depending on the interface might depend on methods they don’t care about.

                   +----------------------------+
             | <<Interface>>              |
             |      IVehicle              | <-- Fat Interface
             +----------------------------+
             | + drive()                  |
             | + fly()                    |
             | + sail()                   |
             +----------------------------+
                         ^
               implements|
             +----------------------------+
             |         Car                |
             +----------------------------+
             | + drive()                  |
             | + fly() { // Not needed! } |
             | + sail() { // Not needed! }|
             +----------------------------+
Client needing only drive() still depends on fly() and sail() methods.

      Good: Smaller, role-based interfaces. Classes implement only the interfaces relevant to them. Clients depend only on the specific interfaces they need.

      +---------------+  +---------------+  +---------------+
| <<Interface>> |  | <<Interface>> |  | <<Interface>> | <-- Segregated Interfaces
|   IDrivable   |  |   IFlyable    |  |   ISailable   |
+---------------+  +---------------+  +---------------+
| + drive()     |  | + fly()       |  | + sail()      |
+---------------+  +---------------+  +---------------+
       ^                  ^
implements |                  | implements
+---------------+      +---------------+
|      Car      |      |   Airplane    |
+---------------+      +---------------+
| + drive()     |      | + fly()       |
+---------------+      +---------------+

Client needing drive() depends ONLY on IDrivable.
Client needing fly() depends ONLY on IFlyable.

D – 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. Additionally, abstractions should not depend on details; details should depend on abstractions. This principle encourages the use of interfaces or abstract classes to decouple components.

Example:

Instead of a class directly instantiating its dependencies, it can receive them through constructor injection, allowing for greater flexibility and easier testing.

class Database:
    def connect(self):
        pass

class UserRepository:
    def __init__(self, database: Database):
        self.database = database

    def get_user(self, user_id):
        # Logic to get user from the database
        pass

  • Concept: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.  

  • Diagram:

    • Bad: High-level module (UserRepository) directly depends on a concrete low-level module (MySQLDatabase). This creates tight coupling.

      +-----------------+  depends directly on concrete implementation --> +----------------+
| UserRepository  |                                                  | MySQLDatabase  |
| (High-Level)    | -----------------------------------------------> | (Low-Level)    |
+-----------------+                                                  +----------------+
| - db: MySQLDatabase |                                                  | + connect()    |
| + getUser()     |                                                  +----------------+
+-----------------+
     (Tightly Coupled)

    • Good: Both high-level (UserRepository) and low-level (MySQLDatabase, PostgresDatabase) modules depend on an abstraction (IDatabase). The dependency is inverted (points towards the abstraction). The high-level module receives the dependency (often via injection).

                                   +-----------------+
                             | <<Interface>>   |
                             |   IDatabase     | <-- Abstraction
                             +-----------------+
                             | + connect()     |
                             | + query()       |
                             +-----------------+
                                ^           ^
                       implements |           | implements
         (Low-Level Details depend on Abstraction)
+----------------+                  +-------------------+
| MySQLDatabase  |                  | PostgresDatabase  |
| (Low-Level)    |                  | (Low-Level)       |
+----------------+                  +-------------------+
| + connect()    |                  | + connect()       |
| + query()      |                  | + query()         |
+----------------+                  +-------------------+

+-----------------+  depends on Abstraction --> +-----------------+
| UserRepository  |                             | <<Interface>>   |
| (High-Level)    | --------------------------->|   IDatabase     |
+-----------------+                             +-----------------+
| - db: IDatabase | <---- (Injected)
| + getUser()     |
+-----------------+
     (Loosely Coupled via Abstraction)

Conclusion

The SOLID principles provide a robust framework for designing software that is modular, maintainable, and scalable. By adhering to these principles, developers can create systems that are easier to understand and modify, ultimately leading to higher quality software and improved productivity. Implementing these principles may require a shift in thinking, but the long-term benefits are well worth the effort.

Last updated on April 20, 2025

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *