Solid Principles in c#

Solid Principles in c#

It is design principles that it helps to manage with most software design.

It helps in development to manage design and logic principles.

Solid means are :

1. S: Single Responsibility Principle (SRP)
2. O: Open closed Principle (OSP)
3. L: Liskov substitution Principle (LSP)
4. I: Interface Segregation Principle (ISP)
5. D: Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP):

• Each class and module should focus on a single task at atime
• Everything in the class should be related to that single purpose
• There can be many members in the class as long as they related to the single responsibilty With SRP,classes become smaller and cleaner
• Code is less fragile.
•  a class should have only one reason to change.
• Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibilty should be entirely encapsulated by the class
• Refer to c# tutorial playlist for more details on object oriented principles

Motivation

• Maintainability
• Testability
• flexibility and Extensibility
• Parallel Development
• Loose Coupling
• Solid principles and design pattern plays key role in the above motivations

For Single responsibility interface should be separate for this concern.

Open Closed Principle

• Software entities such as classes,modules,functions,etc. should be open for extension,but closed for modification.
• Any new functionality should be implemented by adding new classes,attributes and methods,instead of changing the current ones or existing ones.
• Bertrand Meyer originated the term OCP
• Robert C. martin considered this as most important principle

Implementation Guidelines

• The simplest way to apply OCP is to implement the new functionality on new derived classes
• Allow Clients to access the original class with abstract interface

Why OCP?

If not followed

• End up testing the entire functionality
• QA team need to test the entire flow
• Costly process for the organization
• Breaks the single responsibility as well
• Maintenance overheaads increase on the classes

For Example:

A bank offers various types of the savings accounts (Salary Saving, Regular Saving and so on) that meet the needs of many types of customers. A bank has differing sets of rules and each savings account type has a different set of rules to calculate interest.
See the following below pic:

Let us try to understand this
For modification we separate this into interface.
See the following pic:

Liskov Substitution Principle (LSP)

What means LSP??

1. s is a subtype of T,then objects of type t may be replaced with objects of type S.
2. Derived types must be completely substituteable for their base types.
3. Liskov substitution principles(LSP) is a particular definition of a subtyping relation,called(strong) behavioral subtyping.
4. This principle is introduced by Barbara Liskov.
5. This principle is distinguished for extension of the open close principle

Implementation Guidelines:

1. No new exceptions can be thrown by the subtype unless part of the existing exception hierarchy
2. we should also insured that client should not know which subtype of their calling.
3. New derived classes just extend without replacing the functionality of old classes.

Example:

Let us understand this suppose I have rectangle class

class Rectangle {

    int getHeight()

    void setHeight(int value)

    int getWidth()

    void setWidth(int value)

}

class Square : Rectangle { }

Do you understand in this scenario a interface matches. Because Rectangle is mathematical definition of squares 

This means if you are getting the Rectangle object just by using a factory dll or from any service where you have no idea what type of rectangle object will be return.

So there will be a big problem

So solution is 

we must make sure that new derived classes are extending the base classes without changing their behavior"

Interface Segregation Principle

1. No client should be forced to depend on methods it does not use
2. One fat interface need to be split to many smaller and relevant interfaces so that clients can know about the interfaces that are relevant to them
3. this principle was first used and formulated by Robert C. Martin while consulting for xerox

Case study:Problem

1. As we all know Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing along with the regular printing task
2. The software for this system was created from the ground up .
3. Modification and Deployment to the system became more complex.

Note: The design problem was that in single class was used by almost of all task whenever a print job or stapling job be performed a call was made to the big job class.
To cure this problem Robert Mrtins has suggested
this ISP principle

Solution 

One large Job class is segregated to multiple interfaces depending on the requirement.

Let us understand with following code and picture.

Dependency Inversion Principle

1. High level modules should not depend on low-level modules.Both should depend on abstractions
2. abstraction should not depend on details .Details should depend on abstractions.
3. The interaction between high level and low level modules should be thought of as an abstract interaction between them
4. This principle was introduced by Robert C Martin

Note: Before understanding of intention of usage let's try to understand a traditional application of architecture in application during the process of design lower level components trying to consumed of higher level components enable increasingly complex systems to be build in this process of composition higher level components depend directly on lower level of task.

So this does not follow of DIP
Now see the below code and picture.

Notice that business layer directly  depend on lower level data access layer. It is very hard to perform unit test. Off course it is bad idea and much more complex.

Hence based on inversion principle we apply on abstraction to T-coupled this layer.
In order to achieve that we introduced that we use Interface and repository We have used.

If we look this code based on above pictorial representation diagram we have introduced interface which are extended by the data access-layer and referred in the business logic-layer

Real Example 
Adapter design pattern applying dependency inversion principle