SOLID Principles of Object-Oriented Design | SOLID
SOLID Principles are one of the mandatory questions in each and every interview. Sometimes it is for all the principles or sometimes any individual named principles, but there will be at least one question on this topic in every interview.
We will see each and every SOLID Principle in this series. In this part, we will only walk through the definitions of all the SOLID Principles, but in the upcoming parts, we will walk through each and every SOLID Principle in detail with live real examples.
Introduction
Design Principles are a set of generalized pieces of advice or proven good coding practices that are used as rules of thumb when making design choices. Design Principles are more abstract and generalized.
SOLID Principles are not any hard and fast rule, but they are guideline principles or ethics that should be followed while designing and developing the application. These five software development design principles are guidelines to follow when building software so that it is easier to scale and maintain.
SOLID Principles are not which is invented by someone, it is a result of continuous problem-solving solutions which are provided by different persons. With the passage of time, new updates are added to these principles. It is also not guaranteed that the current SOLID Principles will be applicable as it is in the future also.
So applying the SOLID Principles is a goal, not a destiny. These SOLID Principles are intended to make software designs more understandable, flexible, and maintainable. All the SOLID Principles work together.
There is no object-oriented programming language that can force these principles or check the existence of these principles in any application.
Object-Oriented Design Principles (OOD)
The Object-Oriented Design Principles expose the dependency management aspects of OOD. Poor dependency management leads to code that is hard to change, fragile, tight coupling, and non-reusable. On the other hand, when dependencies are well managed, the code remains understandable, flexible, robust, and reusable.
There are different categories of Object-Oriented Design Principles. The first five principles are principles about class design known as SOLID Principles.
The next six principles are about packages. A package is a binary deliverable (JAR or DLL file). The first three package principles are about package cohesion. They tell us what to put inside packages:
The Release Reuse Equivalency Principle (REP): "The granule of reuse is the granule of release."
The Common Closure Principle (CCP): "Classes that change together are packaged together."
The Common Reuse Principle (CRP): "Classes that are used together are packaged together."
Finally, the last three principles are about the couplings between packages. They talk about metrics that evaluate the package structure of a system:
The Acyclic Dependencies Principle (ADP): "The dependency graph of packages must have no cycles."
The Stable Dependencies Principle(SDP): "Depend in the direction of stability."
The Stable Abstractions Principle(SAP): "Abstractness increases with stability."
Design Principles encourage us to create more maintainable, understandable, and flexible software. Adopting these practices contributes to avoiding code smells, refactoring code, and Agile or Adaptive software development. In this article, we will walk through the definitions of SOLID Principles.
SOLID Principles
SOLID Principles are the First Five Principles of Object-Oriented Design. These SOLID Principles expose the Dependency Management aspects of Object-Oriented Design (OOD).
The SOLID Design Principles were first introduced by the famous Computer Scientist Robert Cecil Martin (Uncle Bob) in his paper "Design Principles and Design Patterns" in the year 2000. But the SOLID acronym was introduced later around 2004 by Michael Feathers.
These SOLID Principles are used to create understandable, readable, and testable code that many developers can collaboratively work on. These SOLID Principles help to reduce the tight coupling between software components.
So SOLID is nothing but a mnemonic acronym of below five broadly categorized principles:
S- Single Responsibility Principle (SRP)
O- Open-Closed Principle (OCP)
L- Liskov's Substitution Principle (LSP)
I- Interface Segregation Principle (ISP)
D- Dependency Inversion Principle (DIP)
1. Single Responsibility Principle (SRP)
The Single Responsibility Principle is the first SOLID Design Principle. The Single Responsibility Principle states that a class should do only one thing and therefore it should have only one reason to change.
The term "Single Responsibility Principle" was introduced by Robert C. Martin in an article by the same name as part of his "Principles of Object-Oriented Design" in the year 2003 in his book "Agile Software Development, Principles, Patterns, and Practices".
This principle is based on the principle of cohesion as described by Tom DeMarco in his book "Structured Analysis and System Specification" and Meilir Page-Jones in "The Practical Guide to Structured Systems Design".
According to Robert C. Martin, the Single-responsibility Principle (SRP) states that:
A class or module should have one, and only one, reason to be changed.
In other words:
"There should never be more than one reason for a class to change"
Explanation:
Every class should have only one responsibility. If the class has only one job, then also it should have one and only one reason to change.
2. Open-Closed Principle (OCP)
The Open-Closed Principle is the second SOLID Design Principle. The Open-Closed Principles is first proposed by Bertrand Meyer in his book "Object-Oriented Software Construction" in the year 1988 but it was updated by Robert C. Martin later in the 1990s.
The Open-Closed Principle said that classes should be open for extension and closed to modification. Here modification means changing the code of an existing class, and extension means adding new functionality.
According to Bertrand Meyer, the Open-Closed Principle states that:
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
In other words:
"Class should be extendable without modifying the class itself."
Since Bertrand Mayer proposes the Inheritance Based Open-Closed Principle to achieve this goal, and inheritance introduces tight coupling if the subclasses depend on implementation details of their parent class.
That's why Robert C. Martin redefined the Open-Closed Principle to the Polymorphic Open-Closed Principle. It uses interfaces instead of SuperClasses to allow different implementations which you can easily substitute without changing the code that uses them.
In contrast to Meyer's definition, this definition advocates inheritance from abstract base classes or interfaces. Interface specifications can be reused through inheritance but implementation need not be.
The existing interface is closed to modifications and new implementations must, at least minimum, implement that interface. The interfaces are closed for modifications, and you can provide new implementations to extend the functionality of your software.
Explanation
A module or class is be said to be open if it is still available for the extension means new fields, properties, or functions can be added on which it performs.
A module or class is said to be closed if it is available only for use by other modules or classes means the module has been given a well-defined, stable description.
A class is closed, since it may be compiled, stored in a library, baselined, and used by many client classes. But at the same time, it is also open, since any new class may use it as a parent class, adding new features into it. By doing so, there is no need to change the original base class or to disturb its clients.
3. Liskov Substitution Principle (LSP)
Liskov's Substitution Principle is the third SOLID Design Principle. This principle extends the Open-Closed Principle by focusing on the behavior of a SuperClass and its SubTypes. This principle is based on the "Design by Contract (DbC)" approach of software designing.
The Liskov Substitution Principle is a particular definition of a Behavioral Subtyping Relation, that was initially introduced by Barbara Liskov in the year 1987 in a conference keynote titled "Data Abstraction and Hierarchy".
According to Barbara Liskov, this principle states that:
Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.
In other words:
"If S is a subtype of type T, then objects of type T may be replaced with objects of type S without any breaking change."
OR
"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."
So the Liskov Substitution Principle states that subclasses should be substitutable for their base classes.
Explanation
This means that every subclass or derived class should be substitutable for their base or parent class without breaking the application.
For example, if the class S is a subclass of class T, we should be able to pass an object of class S (child class) to any method that expects an object of class T (base class) and the method should not give any weird output in that case.
This should be the expected behavior because in inheritance the child class inherits everything that the superclass has. The child class extends the behavior but never narrows it down.
4. Interface Segregation Principle (ISP)
The Interface Segregation Principle is the fourth SOLID Design Principle. Segregation means keeping things separated, and the Interface Segregation Principle is about separating the interfaces.
The Interface Segregation Principle was first used and formulated by Robert C. Martin while consulting for Xerox to help them build the software for their new printer systems.
According to Robert C. Martin:
Clients should not be forced to depend upon interfaces that they do not use.
In other words:
"Many client-specific interfaces are better than one general-purpose interface."
Interface Segregation Principle splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
Explanation
A client should never be forced to implement an interface that it doesn’t use, or clients should not be forced to depend on methods they do not use. This is only achievable if you define your interfaces so that they fit a specific client or task.
So larger interfaces should be split into smaller ones. By doing so, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them.
5. Dependency Inversion Principle (DIP)
The Dependency Inversion Principle is the fifth and last SOLID Design Principle. The principle of Dependency Inversion refers to the decoupling of software modules.
The Dependency Inversion Principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions. This way, instead of high-level modules depending on low-level modules, both will depend on abstractions.
According to the Dependency Inversion Principle:
Depend upon abstractions, not concretions i.e Entities must depend on abstractions, not on concretions.
In other words:
"The high-level module must not depend on the low-level module, both should depend on abstractions."
Explanation
The Dependency Inversion Principle focuses on the decoupling of modules. It points out below two things:
- High-level modules should not depend on low-level modules. Both should depend on the same abstractions (interface).
- Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.
Advantages of SOLID
When developers work on design without using structured design principles, they can create long-lasting problems in the future for the project, and limit the potential success for the application. These issues are commonly referred to as “code rot.” Some common issues are:
Rigidity: where a small change causes the entire system to rebuild.
Fragility: where changes to one module cause other unrelated modules to misbehave.
Immobility: where a module’s internal components cannot be extracted and reused in new environments.
Viscosity: where building and testing are difficult to perform and take a long time to execute.
Conclusion
All the SOLID Principles serve the same purpose i.e to create understandable, readable, loosely coupled, and testable code that many developers can collaboratively work on.
SOLID Principles in short:
Single Responsibility Principle: "A class should have one, and only one reason to change."
Open Closed Principle: "Objects or entities should be open for extension but closed for modification"
Liskov Substitution Principle: "Derived classes must be substitutable for their base classes."
Interface Segregation Principle: "Many client-specific interfaces are better than one general-purpose interface."
Dependency Inversion Principle: "Depend on abstractions, not on concretions."
Recommended Articles
Static Class and Methods in C#
Constructor and Types of Constructors in C#
Dynamic Polymorphism C#
External Reference Links
Single Responsibility Principle
Posts
No comments:
Post a Comment
Please do not enter any HTML. JavaScript or spam link in the comment box.