Skip to content

Design Patterns SOLID Principles

Links: 107 Design Patterns Index

SOLID Design Principles

  • These were introduced by Robert C Martin (a.k.a Uncle Bob).

Single Responsibility Principle (S)

Your package/struct/class should have a single primary responsibility
  • Separation of concerns
  • Putting everything in a single place is an anti-pattern and is also known as a God object/class.
  • For example
    • If you have a journal struct then it should only be responsible for adding, removing and listing entries from the journal
    • It should not be concerned with persistence like saving it to a file or uploading it somewhere.
    • It should be handled by other functions or package. This way we are making sure we are not making a God Class/Object.

Open Closed Principle (O)

It states that types should be open for extension but closed for modification.
  • Enterprise Pattern : Specification
  • Illustration of Open Closed Principle is very well illustrated with the Specification pattern
  • The specification pattern uses a bunch of interfaces
Try to remember the colour specification pattern.

Liskov Substitution Principle (L)

  • It primarily deals with inheritance and is directly not applicable to Go.

Interface Segregation Principle (I)

  • It is the simplest principle in SOLID.
It states that you shouldn't put too much in an interface.

Try to split up the interface.

Last updated: 2022-07-07