S.O.L.I.D Principles using C#

And the principles are…

S    Single Responsibility Principle
O   Open Closed Principle
L    Liskovs Substitution Principle
I     Interface Segregation Principle
D   Dependency Inversion principle

Single Responsibility Principle

   “A class should have one reason to change” 
   Meaning
   There can be only one requirement that when changed, will cause a class to change.
   
   How to do this ? 
   breaking your story/requirement/code  to smaller chunks/class in such a way that all common behavior is being grouped together under one component.

Single Responsibility means your class to be very focused  

Outcome
You will end up having multiple classes, precise about one specific behavior. Each of this class can now be used as a component.

Open Closed Principles

“Your class/module/contracts should be open for extension and closed for modification”
Meaning 
You should be able to extend the behavior of a class without changing it.
Once a class is done, it should not be modified.

How to do this ? 
Creating new class by using inheritance
or
abstraction

Open Closed Principle

To implement OCP, we should be SRP, 
so that we can identify and separate behavior that change into multiple classes, such that
things that change frequently depends on things that don’t.
Output
Lots of components(class) for same behavior but different implementation

Liskovs Substitution Principle

“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of  T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.”
Meaning
We should be able to substitute every derived class for there parent class. A subclass (outcome of OCP) should behave in such a way that it will not cause problem when used instead of its super class(outcome of SRP)

Liskovs Substitution Principle

How to do this ?
Pre conditions cannot be strengthened in a subtype 
& 
Post conditions  can not be weakened in a subtype.

No new exceptions types are allowed to be thrown unless they are subclasses of previously used one.   

You can not make mutable to immutable vice versa.
Output
Plug and play components.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they don’t use.”

How to do this?
Breaking down interfaces in smaller pieces and combining interfaces to generate a super interfaces.

Output
Smaller Interfaces with specific responsibility.

Dependency Inversion Principle

“High level module should not depend on low level module. Both should depend on abstraction.
Abstraction should not depend upon details. Details should depend upon abstraction.”
Meaning 
Your classes should not depend on specific implementation, avoid instantiation of a class X inside another Y, as this makes your class Y directly dependent on X and any change in X might break Y. 

Dependency Inversion Principle

Example:





       




If business decides to change Business Logic or database, this model does for a complete change, because business login is directly instantiating  repository layer and same for UI. UI is calling business logic layer by directly creating an object of it. 
       We should not use NEW keyword inside a class as this creates a dependency.


How to do this?
By using Interfaces or Abstract classes to create generic types or holder to hold any class implementing that interface or abstract class.
By not using NEW keyword to instantiate an object and instead inject the dependencies using constructor or property.


If NEW is not to be used, then who will create required object?
We achieve this by using Dependency Injection tools like Unity, Structure Map.
By having a Abstract Factory Method responsible for create of new object.



 

Done !!!

Few Points to consider…
Try avoiding over engineering  and keep the solution simple  and readable.

Decide how far you want to go with SOLID, as splitting requirement to SOLID principles is debatable.

Project size (LOC)