SOLID
It often happens that we write some code, throw it into the proverbial drawer and
remember about it after some time. We forget to at least comment on it and structure
looks like someone wrote a poem from the first to the last line despite the fact that we
write in object-oriented languages like C#, Java or Python. With the help comes SOLID,
which is worth knowing about and understanding.
What is SOLID?
SOLID is a set of good architectural practices in object-oriented programming, helping to make our code more understandable, flexible to change and easier to manage. The methodology was invented long ago and endorsed by Clean Code Developers such as Robert C. Martin. It was first proposed by Michael Feathers. It is a better way of thinking and looking at how to design object-oriented applications.
Five basic rules
S (Single Responsibility Princple) – It implies that the responsibility for our class or method should be single. We shouldn’t desire to change our class for more than one reason.
Imagine you have a toolbox. Each tool in the toolbox serves a specific purpose, like a hammer for pounding nails. Similarly, in programming, each class should have a single responsibility. This means that a class should do just one thing and do it well. If a class does too many things, it becomes harder to understand, modify, and maintain.
Theory
Example
S (Single Responsibility Princple) – which means that our class or method should have only one responsibility. There should not be more than one reason for us to want to modify our class.
Imagine you have a toolbox. Each tool in the toolbox serves a specific purpose, like a hammer for pounding nails. Similarly, in programming, each class should have a single responsibility. This means that a class should do just one thing and do it well. If a class does too many things, it becomes harder to understand, modify, and maintain.
O (Open Close Principle) – which tells us that our classes or its entities should be closed to modifications and open to extensions. We should not touch existing code that works in a production environment which can cause an error. We should be able to make changes by extending the code and not modifying it.
Think of your favorite puzzle. You can add new pieces to it without changing the existing pieces. The Open/Closed Principle works similarly. It states that classes should be open for extension but closed for modification. This means that you can add new features without changing the existing code. This makes your software more adaptable to changes.
L (Liskov Substitution Principle) – which means, in simple terms, that the inheriting class should extend the base class without affecting its current operation.
Imagine you have a remote control for your TV. You expect all buttons to work as they’re supposed to. In programming, the Liskov Substitution Principle says that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program. In simpler terms, if you have a base class and a derived class, you should be able to use the derived class wherever you use the base class.
I (Interface Segregation Principle) – In other words, it is the principle of segregation of interfaces. It means that many different interfaces are better than one large and overly elaborate interface. Each interface should be created in such a way that it contains as few methods as possible, i.e. methods that are necessary at the moment. It should not contain redundant methods and all other methods, if not related to a specific interface, should be in separate interfaces.
Think of a cafeteria where you can choose only the food you want. The Interface Segregation Principle is similar. It suggests that a class should not be forced to implement interfaces it doesn’t use. Instead of having one big interface, it’s better to have smaller, specific ones. This prevents unnecessary dependencies and makes your code more focused.
D (Dependency Inversion Principle) – That is, the principle of dependency reversal. It tells us that high-level modules should not depend on low-level modules and all should depend on the abstraction layer. In other words, we should not operate directly on instances of our classes, variables, objects or methods but on their interfaces, which are their layers of abstraction and allow us to extend and make changes.
Picture a stack of building blocks. You can change the arrangement of the blocks without changing their properties. The Dependency Inversion Principle is about high-level modules not depending on low-level modules. Both should depend on abstractions. This helps in decoupling the components of your software, making it easier to replace or modify parts without affecting the whole system.