Which are the SOLID principles in object-oriented programming ?

The term SOLID in the world of development represents 5 important principles that respect some rules and guidelines for the OOP and particularly in the .NET world. It's a mnemonic acronym that I'm going to describe letter by letter in this article and that can be asked during a job interview like it happens to me in New Zealand multiple times.

  • The S represents, "Single Responsibility". This principle implies that your code inside your class should have one responsibility and only one. So your class should have only one type of task to do and if you realize you have 2 different tasks, ask yourself if it's better to break the class into two other classes to respect this principle.
  • The O represents "Open / Close". The reason of this principle is very simple, your class must be open for an extension/update, but must be close for any changes. This method is good to avoid regressions when you had some new features. Of course sometimes, you have some cases when you have to change your class anyway like when you have bugs or something like that. But this principle pushes you to do it less as possible.
  • The L represents, "Liskov Substitution". Just for additional information, Liskov, of her first name Barbara, is a famous computer scientist (Turing’s prize, similar to Nobel Prize) who spoke about this principle start of 90. The liskov substitution, in a simple way, explains that an object S from the subtype T should be able to replace an object of type T without any consequences in behavior of the software. The famous / best example is when you take the rectangle and the square. Because the square is a special type of rectangle, you think you can make an inheritance between each other and, of course, you can but what happen if you try to calculate the area of the Rectangle object created from the square Type ? Which property of the rectangle should we use? Height or Width? To avoid this situation and make it better, the clue is to create a common abstract class super type for the rectangle and the square type and create an abstract method "Area()" inside where each class will implement.
  • The I represents "Interface segregation" which is a way where the main idea is to create multiple interfaces rather than only one with too many methods inside. The goal is to slip the different tasks and keep the focus for each of them on a special thing to do. This method makes the unit tests easier, a better decomposition of the code and therefore a better understanding in general.
  • The D represents  "Dependency Inversion" which the goal is to invert the dependencies between modules in your application. Typically, if you take a project with some business code  (Business Layer - BL) and a project which is taken care of the data (Data Access Layer - DAL ), most of the time, your project BL will reference your project DAL. And with this principle, it's completely the opposite that will happen, you won't ever make any reference to DAL in your project BL but you'll create an abstraction and it's from this time that the injection of dependency start. This one has more than one advantage: Make the unit tests easier, handle lifetime objects, replace your DAL project by another (change database for example), etc.

I hope this brief explanation about SOLID will be able to make you understand it better! Don't hesitate to do some research about it to go deeper!