When a software engineer works on a small project which will not be scaled in future and is working with a small team of friends or colleagues its easy to build project without following any guidelines and it wont impact much to end product. The motive is to write clean code and increase re usability. But imagine working on a project which will be scaled up in future to millions users and new features, teams works across geographies and they want to add some features to an existing project. How they can add the new functionality. The one way will be to add function or method in the existing class, but there will always be possibility of breaking things. Imagine working on a huge project and the classes are tightly coupled with 1000's lines of code, this not only make code unreadable but adding features to it makes it vulnerable to failures which we in our hindi language says "code fatt gyaaaa.................."

To save us from all these hassles and to have a common principle while developing scalable projects, there are some guidelines which can be followed.

These guidelines are popularly known as "SOLID":

S-->Single responsibility principle

O-->Open-closed principle

L--> Liskov substitution principle

I-->Interface segregation principle

D-->Dependency inversion principle

1.Single responsibility principle

It is one of the most important of solid principle It says that a single file should have a single class and one class should perform only one task It is best practice to name the class same as its functionality and everything inside it must match its name. If there is a need to change , there must be only one reason to change.

For example if you are making an Employee Management System the Individual Contributor(IC) and Manager should be different class because they have different functionality. In this way if there is any change in class method of Manager ,we dont have to make change in IC class.

2.Open Closed Principle

This rule is about inheritance. It says that the classes should be closed for modification and open for extension. It means that whenever there is a need to add new functionality to existing class, it should be added through inheritance not by modifying the existing one.

The reason is when we inherit from a parent class it should not affect the parent class and it solves the problem of resistance to make change in existing code base.

3.The Liskov Substitution Principle

The Principle is about implementing the inheritance. It says that if you have a function or class B and its using class A, then the replacement of class A by any function of its subclass should not break the functionality of class B

For example if you have a class Rectangle which has a method of calculation Area which takes two parameter (width,height) , and there is another class Square which inherit Rectangle class and override the Area function with parameter(width). In this case we cant replace the object of Rectangle class with the Square class because the code will break due to the extra parameter "height" in Square class. and it violates the Liskov Substitution Principle.

To avoid this we should use optional parameter(*args) "height" in Square Class so that even if the class object is replaced its not breaking the code flow.

Class Rectangle { area(width,height) return width x height } Class Square extends Rectangle { area(width) return width x width //overrides the area method in Square class }

Rectangle obj1= new Rectangle(); Square obj2= new Square(); obj1.area(w,h); obj2.area(w);

In the above case we can't replace the Rectangle object with Square Object and it violates the above principle.

To fix it

Class Square extends Rectangle { area(width,*argv) (if arg in argv)

//overrides the area method in Square class

return width x arg

return width x width;

}

4.The Interface Segregation Principle

A class can implement many interface but we should not overload a class and force it to implement a functionality which probably it doesn't need. If we are following the single responsibility principle, we can avoid this type of situation.

5.The Dependency Inversion Principle

The Class should depend on abstraction not on specific implementation of those abstraction. Abstraction means the interface. Abstact methods only have methods not the body which means its implementation is defined in the class which implements it.

For example, For a bike there can be a method to start We can implement a interface start_Bike(): Now the Bike can start either by kick or self start the methods can be implemented in the class which extend the interface start_Bike.

Here we can note that the interface doesn't define how bike starts its the responsibility of class to define it.