SOLID is a popular set of design principles that are often used in object-oriented software development. The acronym stands for five key design principles which are: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Together these principles are intended to reduce dependencies along with making designs easier to understand, maintain, extend, and avoid issues to build an adaptive, effective, and agile software.
The single responsibility principle is a basic principle that many of us developers are already using daily in our own coding. The idea behind this principle is that every class, module, or function in the program should only have one responsibility or purpose in the program. A commonly used definition to describe this principle is that “every class should have only one reason to change.” Implementing this principle is sure to make your code easier to test, maintain, implement, and can help avoid unanticipated side effects of future changes.
The Open-Closed Principle in summary, is that you should be able to extend a class’s behavior without modifying it. By following this principle can make our code writing easier to maintain and also revise in the future. Our classes would compile with this principle if it is open for extension and closed for modification. Open for extension means that the class’s behavior can be extended. While on the other hand, closed for modification means that the code is set and cannot be changed. This implies that such entities, like classes, functions, objects and so on, should be created in a way that their core functionalities can be extended to other entities without altering the initial entity’s source code.
The Liskov Substitution Principle is one of the most difficult to understand out of the five SOLID principles. This principle simply requires that every derived class should be substitutable for its parent class. The Liskov substitution principle implies that when an instance of a class is passed/extended to another class, the inheriting class should have a use case for all the properties and behavior of the inherited class. So, if we were to extend a class, if some of the properties of the initial class are not useful for the new class, then the principle will be violated. We can easily fix this though by creating an interface that matches the needs of the inheriting class. Following this principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes. It leads to easy extensions of software, and, while it might slow down the development process, following this principle during development can avoid lots of issues during updates and extensions.
The Interface Segregation Principle states that it’s better to have a lot of smaller interfaces than a few bigger ones. This means that you don’t want to just start with an existing interface and add new methods. Instead, start by building a new interface and then let your class implement multiple interfaces as needed. This principle makes us understand that it is unnecessary and unreasonable to create an interface with a lot of methods as some of these methods may be irrelevant to the needs of a particular user when extended.
The Dependency Inversion Principle, simply put, is that developers should depend more on abstractions, not on concretions. For example we should make our classes rely on properties in our interfaces instead of relying on each other. The implications of violating this principle would result in a rigid system where testing blocks of code independently would be very difficult, reusability of code would be near impossible, and the addition or removal of code would lead to further complexity of the system and introduce bugs. High level modules should not depend upon low level modules. Both should depend on abstractions. Furthermore, abstractions should not depend on details. Details should depend upon abstractions.
Overall, the goal of the SOLID principles is to reduce dependencies so that we can change one software without impacting others. With the SOLID principles we can make our code more maintainable, extensible, and flexible. These principles provide a set of guidelines for object-oriented programming and design, with the aim of making code easier to understand, debug, and modify. By following the SOLID principles, developers can write code that is more cohesive and less prone to errors, and that can be easily adapted to changing requirements or new features. Ultimately, the goal of the SOLID principles is to help developers create software that is of high quality, and that is easy to maintain and evolve over time.
https://www.bmc.com/blogs/solid-design-principles/
From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.