What is SOLID principle or architecture ?

S.O.L.I.D is a software design principles or we can say it is OOD that is object oriented design.These principles helps programmers to set of guidelines to avoid bad software design.

What is the role of a software architect in software development.Basically a software architect is responsible to provide a pattern on which programmers have to work.

Every software or application must be fixable and expandable,means whenever any new functionality or module needs to be added,then it should be easily added without much more efforts.

In simple terms an application design must be altered easily for every change request or new feature request. After some time we might need to put in a lot of effort, even for simple tasks and it might require a full working knowledge of the entire system. But we can't blame change or new feature requests.

SOLID principles are set of design principles that enable a way to manage the problems under software design.Robert C. Martin introduced these principles in the 1990's. These principles provide us ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly. SOLID is an acronym of the following.

S: Single Responsibility Principle (SRP)

O: Open closed Principle (OSP)

L: Liskov substitution Principle (LSP)

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle (DIP)

S- SRP (Single responsibility principle)

SRP principle says that every class, or similar structure, in your code should have only one responsibility.It means that whatever a class does,it should have a single job.If you have create a Employee class then it must perform employee related activities rather than doing additional task like error logging,email sending etc.

Here separation of concern comes into the picture,means separate out the entity based on there responsibility that will help to decouple the software application.

Let look into the problem then we will try to understand SRP in best possible way.

If you look into above example,you will find that Employee class is perform AddEmplyee activity that is responsibility of this class but what about Error logging (In catch block), this is not responsibility of an Employee class.

So what is the problem with this code.Let assume that there are many class that are doing error logging and if there is a change in error logging logic then we need to change that logic everywhere.

Below example is the solution by assigning a single responsibility to Employee class.

Now if you look into above example, class Employee has only single responsibility.So now if any change needs to be done ,programmer has to worry about only ErrorLogging class.That all aboub SRP principle.

O - Open/Closed Principle

In simple terms it states that application should be open for extension and closed for modification.
We need to design our module/class in such a way that the new functionality can easily be added only when new requirements are generated. "Closed for modification" means  already developed  class or module can not be altered that has been gone through unit testing. We should  not alter it until we find bugs. As it says, a class should be open for extensions, we can use inheritance to do this. Okay, let's take an example to understand it.

Till now there is no issue with above code.Now it's time to add one more functionality to calculate total salary of part time employee.I think it is not an issue for a programmer,so here we write below code to achieve additional functionality.

So we are done with our new changes and i think there is no issue at all.So it's clear that whenever there is new Customer type introduce we will follow in same way.So where is Open/Closed principle.
Have you imagine that every time we introduce new Customer type we need to modify TotalSalary class which is already implemented and test(assume) then why to change this class every time.(need software testing again and again).Isn't it a bad situation? Here comes the Open/Closed principle.
What open/closed principle say, that classes or modules that are already implemented that are closed for modification but your application should be open to add new changes/functionalities.

How can we make our design to avoid this situation? We can do this by introducing a abstractions for dependencies, such as interfaces or abstract classes, rather than using concrete classes.

Now look at the above code.It has both SRP and OCP. Whenver there is new type introduce you just need to work on that type only,no need to change class that are already implemented.

L - Liskov substitution Principle

Let's dive into liskov's substitution principle,which says that user should be able to use derived class rather than it's base class and it must behave in a same way without any modification in base class.In simple way,derived class will treat as a base class.(as a substitute).

Liskov's principle is an extension to the Open Close Principle and it means that user must ensure that new derived classes inherits the base classes without changing their behavior. Let's play with an example that is quite popular (Example of square and rectangle) that violates Liskov's principle(LSP).

In mathematics conceptually a square is a rectangle whose side and width are same.

So to calculate Area of rectangle and square,we use below code.

Run the program with the below RectangleSet() method and you will unexpecting result 25.What you were expecting - result as 50?? 

So What is wrong with above code?

If you notice LSP principle which stats that "user must make sure that new derived classes inherits the base classes without changing their behavior" .

"Here square classes inherits the rectangle but it is changing it's behavior" 

Ok Lets look into below code


Width=Height is must be rule for  Square not for Rectangle .So when Square object returns from RectangleSet() before calling CalculateArea() user assigns r.SetHeight(10) and r.SetWidth(5) and waiting for a result 50 but getting 25.  It changes the  result that user expecting. But programmer was expecting the result of Rectangle area.

So here violation of Liskov's substitution principle occurs.

Now the solution is to manage the class inheritance hierarchies correctly. Lets introduce another class.

Now change the inheritance hierarchies by making it base class.

Let do what that we actually want.Look into below code-

Now you will get the desired out.I think you have now understood the LSP principle.

I - Interface Segregation Principle (ISP)

If you know that method declared in interface are mandatory to implement in those classes that implementing the interface,Interface segregation principle is all out implementing an interface.

Interface segregation principle "User should not force to implement interface if they don;t require it".To do that instead a single interface divide the interface into small interfaces(each small interface act like a small individual module).

Let's look into below example -

Till now there is no issue that violates ISP.Let us assume Submanager introduced into system,which can only edit role(can't create new role)
Here is the code that violates ISP.

So to overcome with this,what we need to do this - Split the interface into modules as required.Here there are two entities Manager and Sub-Manager so we create interface according to there needs.

Here is the example in which we have divide one interface into 2 parts -

ISubManager interface having edit method
Here we inherts IManager,ISubManager for Manager
Here we inherts ISubManager for SubManager

Here we have separated the functionalities and distributed then to multiple interfaces and overcome the ISP violation.

D: Dependency Inversion Principle

According to Dependency Inversion Principle (DIP) high-level classes or modules should not depend upon classes or modules. Both should depend upon abstractions. 

Secondly,abstractions should not depend upon details. Details should depend upon abstractions.High-level modules or classes implements the business rules or logic of an application. Low-level modules/classes deal with more detailed operations/functionalities, in other words they may deal with writing information to databases or passing messages to the operating system or services.

Above program look good at first sight but this is violating the dependency inversion principle because high level class WriteFile directly depends on low level class ErrorLogWriter.In order to overcome this problem you need to introduce interface. See below example -

In above example, we have created instance of an interface and then using it accordingly,by that way we are eliminating the dependency of high level class on low level class because now dependency lie on interface only.

Hope you have like this post.Please provide your feedback.


Thanks.