Solid Design Principals

S.O.L.I.D STANDS FOR

  • S - Single Respondibility

    A class should have only a single responsibility (i.e. A class should have only one reason to change)

  • O - Open/Close

    Software entities … should be open for extension, but closed for modification

  • L - Liskov substitution Principle (LSP)

    Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program

  • I - Interface Segregation Principle (ISP)

    Many client-specific interfaces are better than one general-purpose interface
    No client should be forced to depend on methods it does not use

  • D - Dependency Inversion Principle

    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.

Single-responsibility Principle

S.R.P for short - This Principle states that:

A class should have only a single responsibility (i.e. A class should have only one reason to change)

Open/Closed Principle

Software entities … should be open for extension, but closed for modification

Liskov substitution principle

LSP for short - This Principle states that:

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program

How is LSP different from Inheritance?

Inheritance => is a relationship
LSP => substitute for relationship

Interface Segregation Principle

ISP for short - This Principle states that:

Many client-specific interfaces are better than one general-purpose interface
No client should be forced to depend on methods it does not use

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.

Dependency Inversion Principal

DIP for short - This Principle states that:

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.

Dependency Inversion: Higher-level module exposing

Figures 1 and 2 illustrate code with the same functionality, however in Figure 2, an interface has been used to invert the dependency

Inversion of Control (IoC)

DIP doesn’t says us how to solve the problem but Inversion of Control defines some way so that we can maintain DIP.

Inversion Of Control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from a generic framework.

Delegate the function of selecting a concrete implementation type for the classes' dependencies to an external component or source.