SOLID Principles

Five design principles intended to make software designs more understandable, flexible, maintainable, scalable, and efficient.

SOLID:

  • Single Responsibility Principle

    A class should have one and only one reason to change, meaning that a class should have only one job.

    • Each module should only be responsible for a single related group of tasks.
    • Each Class should only be responsible for the concept it represents; and each method of a class should only do the job implied by method type(constructor, get/set, built-in object methods, and task methods).
    • Each Function should be dedicated to only one task.
    • Each statement on one line of code should do one job.
  • Open-Closed Principle

    Objects or entities should be open for extension but closed for modification.

    • It means that our software structures(class, function, modules, etc) should be open for extensions, but closed for modification. Meaning they should be extendable without need for modifications.
  • Liskov Substitution Principle

    Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

    • Liskov Substitution Principle (LSP) regulates the use of inheritance. It basically says that, subtypes must be substitutable for their base types. When we derive a new class from a base class, we can substitute this class with any other siblings or parents without getting any error in any point of the architecture.
  • Interface Segregation Principle
    clients should not be dependent on using interfaces they do not use. It aims to get rid of dirty interfaces and contain high cohesion.
  • Dependency Inversion Principle

    Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.
    High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.


Learning Sources: