====== SOLID Principle ======

**Tags:** #solidprinciple #solid #software #softdev #softwaredevelopment

**Last Reviewed:** 29/08/2024
==== 1. Single Responsibility Principle (SRP) ====

  * **Meaning**: A class should have only one responsibility, meaning it should implement strongly related logic to ensure high cohesion.
  * **Example**  (BAD): A ''PlaceOrder''  class that handles stock verification, payment processing, and shipment violates SRP.
  * **Example**  (GOOD): Separate these responsibilities into distinct classes like ''StockAvailability'', ''ProductPayment'', and ''ProductShipment''.
  * **How to Recognize Code Smell?**
      * Multiple contextually separated pieces of code in a single class.
      * Large setup required in tests.
  * **Benefits**:
      * Reusability of separated classes.
      * Easier testing of individual responsibilities.

==== 2. Open/Closed Principle (OCP) ====

  * **Meaning**: Classes should be open for extension but closed for modification. You should be able to add new functionality without altering existing code.
  * **Example**  (BAD): A ''Logger''  class that has if-else logic to handle different logging forms (console, file).
  * **Example**  (GOOD): Create separate classes like ''ConsoleLogger''  and ''FileLogger''  that can be injected into the main ''EventTracker''  class.
  * **How to Recognize Code Smell?**
      * Direct references to other classes within a class.
      * Complex if-else or switch statements.
  * **Benefits**:
      * Easier extension of functionality.
      * Loosely coupled code, enhancing testability.

==== 3. Liskov Substitution Principle (LSP) ====

  * **Meaning**: Subclasses should be substitutable for their base classes without altering the desirable properties of the program.
  * **Example**  (BAD): A ''Square''  class inherits from ''Rectangle''  but changes the behavior of inherited methods like ''set_width''  and ''set_height''.
  * **How to Recognize Code Smell?**
      * Modification of inherited behavior in subclasses.
      * Unexpected results or exceptions in overridden methods.
  * **Benefits**:
      * Avoids incorrect or unexpected behavior in code.
      * Clear distinction between shared inherited interface and extended functionality.

==== 4. Interface Segregation Principle (ISP) ====

  * **Meaning**: Clients should not be forced to depend on interfaces they do not use.
  * **Example**  (BAD): A ''Car''  interface with methods like ''open'', ''start_engine'', and ''change_engine''  that forces classes like ''Drive''  and ''Mechanic''  to implement methods they don’t need.
  * **How to Recognize Code Smell?**
      * Large interfaces with methods not used by all implementing classes.
  * **Benefits**:
      * Highly cohesive code.
      * Reduces coupling by splitting fat interfaces into smaller, client-specific interfaces.

==== 5. Dependency Inversion Principle (DIP) ====

  * **Meaning**: High-level modules should not depend on low-level modules. Both should depend on abstractions, and details should depend on abstractions.
  * **Example**  (BAD): An ''EventTracker''  class directly instantiating a ''ConsoleLogger'', creating high coupling.
  * **Example**  (GOOD): Use dependency injection to inject a logger (e.g., ''ConsoleLogger'') into the ''EventTracker''  class.
  * **How to Recognize Code Smell?**
      * Instantiation of low-level modules within high-level ones.
      * Direct method calls to low-level modules/classes.
  * **Benefits**:
      * Increased reusability of high-level modules.
      * Easier mocking of dependencies in tests.