Skip to content

Instantly share code, notes, and snippets.

@yolossn

yolossn/SOLID Principles in GO

Last active March 14, 2020 18:55
Show Gist options
  • Save yolossn/4ba3fac2c0947a9ef944c9eff5b11bc2 to your computer and use it in GitHub Desktop.
Save yolossn/4ba3fac2c0947a9ef944c9eff5b11bc2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
SOLID Principles in GO
-- S.O.L.I.D --
Single Responsibility Principle.
Open / Close Principle.
Liksov Substitution Principle.
Interface Segrigation Principle.
Dependency Inversion Principle.
Single Responsibility Principle
-------------------------------
A Class should have one and only one reason to Change - Robert C Martin
1. Reduces Coupling in the code. A change in code of one package or struct shouldn't directly
invoke a code change in another struct or package.
2. Reduce Cohesion. Make sure to have clear and small packages which server a single purpose.
Don't have packages like common or private which will serve multiple purpose.
Go Standard Packages follow the unix philosophy. Small sharp tools combine to solve larger tasks.
Open/Close Principle
---------------------
Software Entities should be Open for extension and Closed for modificaiton - Bertrand Meyer
Example:
struct Fruit{
Weight
}
func (f Fruit) Weight() int{
return 10 ✅
}
func (f Fruit) Price(cost int) int{
return cost * f.Weight() ❌
}
Here A Struct inheriting the Fruit can override the Weight and it will work as expected.
But If the same struct uses Price. It will give the incorrect price as the price uses the
Weight function of the fruit and not the inherited struct.
Liskov Substitution Principle
-----------------------------
Don't use the direct instance of a type. Always accept an interface so that the It is easy to accept
another implementation of the interface without any code change.
1. Small Interfaces, Simple Interfaces, Common behaviour.
Ex:
type Reader interface{
Read(buf []byte)(int, error)
}
☝️ This is the io.Reader interface in the Standard Package. Since it is small and simple It can used with
different types of Readers like file reader, stream reader etc.
2. Require no more, Promise no less - Jim Weirich
Interface Segrigation Principle
-------------------------------
Client shouldn't be forced to depend on methods they dont use.
Don't create big struct with a lot of behaviors, we should isolate behaviors.
Example:
type Vehicle struct {
}func (v Vehicle) Accelerate() {
fmt.Println("Accelerating ....")
}func (v Vehicle) PlayCD() {
fmt.Println("Playnig Guns n Roses")
}
A Bus Implementing this interface must not be forced to implement PlayCD.
Also make sure to use proper interfaces in your funcitons. A function which just reads a file
shouldn't use the ReadWrite interface as the function now has the access to Write to the file
and also If we want to replace the function to read from a NFS for some reasin has only read access, it will
lead to either creating a dummy implementation of Write or change the function.
A Great Rule of thumb for Golang is accept interfaces and return structs.
Dependency Inversion Principle.
-------------------------------
High level modules shoudln't be dependent on Low level modules it should be dependent on abstractions.
Abstractions shouldn't be dependent on Details and Details should be dependent on Abstractions. - Robert C Martin
A better designed Go Code shouldn't have circular dependency.
Design is the art of arranging code that needs to work today and easy to change forever.
References:
-----------
https://www.youtube.com/watch?v=zzAdEt3xZ1M&t
https://medium.com/@felipedutratine/solid-interface-segregation-principle-in-golang-49d4bbb4d3f7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment