engineering:computer_science:software_development:solid_principles

SOLID Principle

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

Last Reviewed: 29/08/2024

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • engineering/computer_science/software_development/solid_principles.txt
  • Last modified: 2024/08/29 22:20
  • by carlossousa