S.O.L.I.D principles are a set of five fundamental guidelines in software design that aim to enhance the quality, maintainability, and extensibility of code.
These principles provide a structured framework to create robust and flexible software systems, ensuring that the codebase remains manageable and adaptable as it evolves.
Let's get started with understanding what S.O.L.I.D principles mean
Single Responsibility Principle (SRP): "Separation of concerns"
This principle emphasizes that a class or module should have only one reason to change, meaning it should have a single, well-defined responsibility.
Let's say we want to implement a Journal, we want to be able to, create this journal and add entries to this journal with proper numbering of entries
Now suppose we want to add saving functionality to this Journal , we can resort to adding a save() function in the SAME class , but this would violate the SRP principle , it also leads to tight-coupling of the saving logic with the entry logic
If something in the saving logic is changed we would again have to modify the whole class -which is a bad practice
Since saving is a separate concern it must be handled separately
now every single class has a single reason to change
Other advantages of SRP include Enhanced code readability, Improved maintainability, Ease of testing, Modularity, Code reusability, Easier debugging, Flexible evolution, Reduced complexity, Team collaboration, Documentation and onboarding, Code quality and Adaptation to change
Open/Closed Principle (OCP): "open to extension but closed for modification"
The Open/Closed Principle advocates that software entities, such as classes or modules, should be open for extension but closed for modification. This encourages the use of inheritance, interfaces, and abstract classes to build upon existing functionality without altering the existing codebase.
By following OCP, developers can introduce new features or behaviours without risking unintended side effects in the existing code, thus enhancing code stability and minimizing regressions
Suppose we want to create filtering functionality for certain products on amazon on some criteria, we would want to do something like the below implementation
This type of implementation is not ideal as it causes a cartesian explosion and doesn't scale well as more and more criteria are added
A more robust implementation would be using the Specification Pattern (Enterprise Pattern)
We start by creating a specification interface:
Now a color specification can be specified as
Similarly, a Size specification can be specified as follows
Now that we have a way to handle our specifications we create a Filter Interface
Now concrete Implementation of this filter would look like this:
In the problem setup we saw how the addition of multiple criteria was causing an explosion of functions in our class-state space explosion, let see how that is resolved here
Now our specifications can be combined without modification, but with extension
Liskov Substitution Principle (LSP): "Substypes should be substitutable for base types."
Objects in a program should be replaceable with instances of their subtypes w/o altering the correctness of the program
Subclass should extend the capability of the parent class and not narrow it down.
For example, consider we have a rectangle class and a utility that we intend to use to set the rectangle height to 10 leaving the width unchanged
now we decide to extend a square from this rectangle, needless to say passing a square (which is also a valid rectangle as per implementation) in the same utility would give faulty results
A possible resolution here would be removing the inheritance between Rectangle and Square and instead, creating separate classes for Rectangle and Square without any inheritance relationship.
Interface Segregation
We should create interfaces such that our implementor only implements what they need
Suppose we want to create an abstraction for a printer/fax/scanner or any composition of these three
A better approach would be to segregate the interfaces, then classes only implement the interfaces they want
This also makes them easy to compose and reuse
Dependency Inversion Principle
IDEA1: High-level modules should not depend on low-level modules. // Both should depend on abstractions.
IDEA2: Abstractions should not depend on details. Details should depend on abstractions.
Suppose we want to model relationships between people
We create a low-level module that stores our relationships- this is a low-level module
Now if we want to perform research on the data we would need a high-level module,
This high-level module for researching has to have the data - the bad thing to do and the thing which will violate the dependency inversion principle is to take this data directly from the low-level module
In the above code if the implementation of a low-level module changes ie
relationshipsbecome a vector of vector instead of a vector of tuples, or it becomes a map of some type the high-level module will break because they are tightly coupledOne of the solutions here is moving the children finding functionality to the low-level module itself, another is introducing an abstraction
Using the above two solutions. We get the same results but in a much safer way without violating DIP
NOTE: Clarity regarding abstractions vs. interfaces
If you want to enforce that a derived class must override a virtual function, you can make the virtual function a pure virtual function by using the = 0 syntax in its declaration. This makes the base class an abstract class, and any derived class must provide an implementation for the pure virtual function to be instantiated.
\=> An abstract class is created by defining at least one pure virtual function in the class.
\=> An interface can be achieved by using a class with all pure virtual functions and no member variables. An interface defines a contract or a set of methods that a class must implement, but it does not provide any implementation itself.