Getting started with SOLID Principles

Photo by Christina @ wocintechchat.com on Unsplash

Today’s software applications are extremely complex. In many cases, a team of developers develops the application. Naturally, certain problems may arise:

1. The difficulty for new team members to study the application: In real life, team members come and go. In complex applications which contain complex modules, classes, and interfaces. Naturally, it will be difficult for new team members to learn the applications.
2. In large-scale projects, there will often be a necessity to modify a class or a module that is used often and that many other objects may be dependent on it. If we modify this class then we will expose the application to new potential bugs that may arise from it.
3. If we modify a class that many other classes depend on then there will be a risk that we will break its backward compatibility. Other classes that depend on this class may behave unexpectedly.
4. If we will build objects that many other objects will depend on there is a risk that the parent components will not need or be able to use all of their functionalities. The code will be cumbersome and filled with unnecessary functions.
5. There is also a risk that if we change something in a specific object there will be a necessity to alter its dependent objects as well.

In the year 2000, Robert C. Martin (also known as Uncle Bob) published a document, which contains five principles to design software projects. Here is the link to the original document. These five principles were later known as the S.O.L.I.D principles. Here is a list of these five principles. For more details about each principle, please click on the link of each principle:

1. Single responsibility principle: Every class, module or object should have responsibility for one task.
2. Open Closed principle: A class, module, or object may be open for extension but closed for modification
3. Liskov substitution principle: Any subclass should be able to completely replace its parent class by all its methods and properties.
4. Interface segregation principle: No component should depend on properties and methods it does not use.
5. Dependency inversion principle: Hi level modules should not depend on low-level modules.