SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle Bob). These principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows. Adopting these practices can also contribute to avoiding code smells, refactoring code, and Agile or Adaptive software development.

The Single Responsibility Principle

One class should have one, and only one responsibility.
There should not be more than one reason for a class to change.
Some good packages in Go standard library are:
  • net/http: This provides Http Client/Server
  • encoding/json: This implements JSON serialization / deserialization

Open-Closed Principle

Objects or entities should be open for extension but closed for modification.
We should be able to extend a class's behavior without modifying it meaning we should be able to change behavior of a object or entity by overriding some class methods or injecting configurations.

Liskov Substitution Principle

Derived type must be substitutable of their base types.
Function that use pointer or references to base classes must be able to use objects of derived classes without knowing it. As we know object-orientation is enabled by composition (prototype pattern), rather than class hierarchies. So through this principle does not imply as strongly as other languages.
The interface should be able to suffice for all struct that implements interface.

Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.
Many client-specific interfaces are better than one general-purpose interface.

Dependency Inversion Principle

Entities must depend on abstractions, not on concretions.
It states that the high level modules must not dependent upon low level modules but they should depend upon abstractions meaning abstraction should not depend upon details and details should depend upon abstraction.
In Go this principle boils down to: Every package should have interfaces that advertise functionality without the implementation specifics. When package needs a dependency, it should take that dependency as a parameter.

Final Thought

In this article, you were presented with the five principles of SOLID Code. Projects that adhere to SOLID principles can be shared with collaborators, extended, modified, tested, and refactored with fewer complications.