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