[Design Patterns] SOLID Principles

✓ Single Responsibility Principle

There should never be more than one reason for a class to change

  • addresses a specific concern

Example

  • Protocol Change: http -> https
  • Message Format Change: json -> xml
  • Communication Security Change: authentication

There is three separate responsibilities then we should have three separate classes of modules

Conclusion

Whenever you’re designing a class or module you should take care that class is addressing only a specific concern so that when a change is needed there is only one reason for a particular class to change.

✓ Open-Closed Principle

Software entities(classes, modules, methods etc.) should be open for extension, but closed for modification.

  • Extend existing behavior
  • Derive from base class and override methods

Closed for Modification:

  • Existing code remains unchanged
  • Avoid modifying base class

If the Base Class that is already written and tested needs to extend or modify behavior of one of the methods that is written in this class, then use inheritance and override the method.

✓ Liskov Substitution Principle

We should be able to substitute base class objects with child class objects and this should not alter behavior/characteristics of program.

✓ Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.

  • Don’t make your interface bigger
  • Don’t put unrelated methods in one interface

✓ 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.

Originally published at https://velog.io.

Backend & Blockchain Developer