We have discussed STUPID issues in programming. The shared modules and tight coupling leads to dependency issues in design. The SOLID principles address those dependency issues in OOP.
SOLID acronym was popularized by Robert Martin as generic design principles dictated by common sense in OOP. They mainly address dependencies and tight coupling. We will discuss SOLID one by one and try to relate each of them with the underline problems and how they try to solve them.
– S – Single Responsibility Principle – SRP
“There should not be more than one reason for something to exist.”
As the name suggest, a module/ class etc. should not have more than one responsibility in a system. The more a piece of code is doing, or trying to do, the more fragile, rigid, and difficult to (re)use it gets. Have a look at the code below:
class EmployeeService
{
//constructor(s)//
Add(Employee emp)
{
//…..//
using (var db = new <Some Database class/ service>()) // or some SINGLETON or factory call, Database.Get()
{
try
{
db.Insert(emp);
db.Commit();
//more code
}
catch(…)
{
db.Rollback();
}
}
//….
}
}
All looks good yes? There are genuine issues with this code. The EmployeeService has too much responsibilities. The database handling should not be a responsibility of this class. Because of baked in database handling details, the EmployeeService has become rigid and harder to reuse or extend for multiple databases, for example. It’s like a Swiss knife; it looks easy but very rigid and inextensible.
Let’s KISS (keep it simple, stupid) it a bit.
//…
Database db = null;
public EmployeeService ()
{
//…
db = Database.Get(); // or a constructor etc.
//..
}
Add(Employee emp)
{
//…
db.Add<Employee>(emp);
//..
}
We have removed the database handling details from the EmployeeService class. This makes the code a bit cleaner and maintainable. It also ensures that everything is doing their job and their job only. Now the class care less about how the database is handled and more about Employee, its true purpose.
Also note that, SRP does not mean a structure/ class will only have a single function/ property etc. It means a piece of code should only have one responsibility related to the business: An Entity service should only be concerned about handling entities and not anything else like database handlings, logging, handling sub entities directly (like saving employee address explicitly) etc.
SRP might increase total number of classes in a module but it also increases their simplicity and reusability. This means in a longer run the codebase remains flexible and adoptive to changes. Singletons are often regarded as opposite of SRP because they quickly become God objects doing too many things (Swiss knife) and introducing too many hidden dependencies into a system.
– O – Open Close Principle – OCP
“Once done, don’t change it, extend it”
A class in a system must not be open to any changes, except bug fixing. That means we should not introduce changes to a class to add new features/ functionality to it. Now this does not sound practical because every class would evolve relatively to the business it represents. The OCP says that to add new features, the classes must be extended (open) instead of modified (close). And this introduces abstractions as a part of a business need to add new features into classes, instead of just a fancy have-it.
Developing our classes in the form of abstractions (interfaces/ abstract classes) provides multiple implementation flexibility and greater reusability. It also ensures that once a piece of code is tested, it does not go through another cycle of code changes and retesting for new features. Have a look the above EmployeeService class.
class EmployeeService
{
void Add(Employee emp)
{
//..
db.Add<Employee>(emp);
//…
}
//…
}
Now if there was a new requirement that would request an email to be sent to the Finance department, if the newly added employee is a contractor, say. We will have to make changes to this class. Let’s redo the service for the new feature.
void Add(Employee emp)
{
//..
db.Add<Employee>(emp);
if (emp.Type == EmplolyeeType.Contractor)
//… send email to finance
//…
}
//…
The above, though seems straightforward and a lot easier, is a code smell. It introduces rigid code and hardwired conditioning into a class that would demand retesting all existing use cases related to EmployeeService on top of the new ones. It also makes the code cluttered and harder to manage and reuse as the requirements evolve with time. Instead what we could do is be close to modifications and open to extensions.
interface IEmployeeService
{
void Add(Employee employee);
//…
}
And then;
class EmployeeService : IEmployeeService
{
void Add(Employee employee)
{
//.. add the employee
}
}
class ContractorService: IEmployeeService
{
void Add(Employee employee)
{
// add the employee
// send email to finance.
}
}
Of course, we could have an abstract Employee service class instead of the interface that will have a virtual Add method with add the employee functionality, that would be DRY.
Now instead of a single EmployeeService class we have separate classes that are extensions of the EmployeeService abstraction. This way we can keep adding new features into the service without having a need to retest any existing ones. This also removed the unnecessary cluttering and rigidness from the code and made it more reusable.
– L – Liskov Substitution Principle – LSP
“If your duck needs batteries, it’s not a duck”
So Liskov worded the principle as:
If for each object obj1 of type S, there is an object obj2 of type T, such that for all programs P defined in terms of T, the behaviour of P is unchanged when obj1 is substituted for obj2 then S is a subtype of T
Sounds too complex? I know. Let us say that in English instead.
If we have a piece of code using an object of class Parent, then the code should not have any issues, if we replace Parent object with an object of its Child, where Child inherits Parent.
Take the same Employee service code and try to add a new feature in it, Get leaves for an employee.
interface IEmployeeService
{
void Add(Employee employee);
int GetLeaves(int employeeId);
//…
}
class EmployeeService : IEmployeeService
{
void Add(Employee employee)
{
//.. add the employee
}
int GetLeaves (int employeeId)
{
// Calculate and return leaves
}
}
class ContractorService : IEmployeeService
{
void Add(Employee employee)
{
// add the employee
// send email to finance.
}
int GetLeaves (int employeeId)
{
//throw some exception
}
}
Since the ContractorService does not have any business need to calculate the leaves, the GetLeaves method just throws a meaningful exception. Make sense, right? Now let’s see the client code using these classes, with IEmployeeService as Parent and EmployeeService and ContractorService as its children.
IEmployeeService employeeService = new EmployeeService();
IEmployeeService contractorService = new ContractorService ();
employeeService. GetLeaves (<id>);
contractorService. GetLeaves (<id2>);
The second line will throw an exception at RUNTIME. At this level, it does not mean much. So what? Just don’t invoke GetLeaves if it’s a ContractorService. Ok let’s modify the client code a little to highlight the problem even more.
List<IEmployeeService> employeeServices = new List<IEmployeeService>();
employeeServices.Add(new EmployeeService());
employeeServices.Add(new ContractorService ());
CalculateMonthlySalary(employeeServices);
//..
void CalculateMonthlySalary(IEnumerable<IEmployeeService> employeeServices)
{
foreach(IEmployeeService eService in employeeServices)
{
int leaves = eService. GetLeaves (<id>);//this will break on the second iteration
//… bla bla
}
}
The above code will break the moment it tries to invoke GetLeaves in that loop the second time. The CalculateMonthlySalary knows nothing about ContractorService and only understands IEmployeeService, as it should. But its behaviour changes (it breaks) when a child of IEmployeeService (ContractorService) is used, at runtime. Let’s solve this:
interface IEmployeeService
{
void Add(Employee employee);
//…
}
interface ILeaveService
{
int GetLeaves (int employeeId);
//…
}
class EmployeeService : IEmployeeService, ILeaveService
{
void Add(Employee employee)
{
//.. add the employee
}
int GetLeaves (int employeeId)
{
// Calculate and return leaves
}
}
class ContractorService : IEmployeeService
{
void Add(Employee employee)
{
// add the employee
// send email to finance.
}
}
Now the client code to calculate leaves will be
void CalculateMonthlySalary(IEnumerable<ILeaveService> leaveServices)
and wallah, the code is as smooth as it gets. The moment we try to do.
List<ILeaveService> leaveServices = new List<ILeaveService>();
leaveServices.Add(new EmployeeService());
leaveServices.Add(new ContractorService ()); //Compile-time error.
CalculateMonthlySalary(leaveServices);
It will give us a compile-time error. Because the method CalculateMonthlySalary is now expecting IEnumberable of ILeaveService to calculate leaves of employees, we have a List of ILeaveService, but ContractorService does not implements ILeaveService.
List<ILeaveService> leaveServices = new List<ILeaveService>();
leaveServices.Add(new EmployeeService());
leaveServices.Add(new EmployeeService ());
CalculateMonthlySalary(leaveServices);
LSP helps fine graining the business requirements and operational boundaries of the code. It also helps identifying the responsibilities of a piece of code and what kind of resources it would need to do its job. This increases SRP, enhances decoupling and reduces useless dependencies (CalculateMonthlySalary does not care about the whole IEmployeeService anymore, and only depends upon ILeaveService).
Breaking down responsibilities sometimes can be a bit hard in complex business requirements and LSP also tends to increase the number of isolated code units (classes, interfaces etc.). But it becomes apparent in simple and carefully designed structures where Tight Coupling and Duplications are avoided.
– I – Interface Segregation Principle – ISP
“Don’t give me something I don’t need”
In LSP, we did see that the method CalculateMonthlySalary had no use of the complete IEmployeeService, it only needed a subset of IEmployeeService, the GetLeaves method. This is, in its basic form, the ISP. It asks to identify the resources needed by a piece of code to do its job and then only provide those resources to it, nothing more. ISP finds real dependencies in code and eliminates unwanted ones. This helps in decoupling code greatly, helps recognising code dependencies, and ensures code isolation and security (CalculateMonthlySalary does not have any access to Add method anymore).
ISP advocates module customization based on OCP; identify requirements and isolate code by creating smaller abstractions, instead of modifications. Also, when we fine-grain pieces of code using ISP, the individual components become smaller. This increases their testability, manageability and reusability. Have a look:
class Employee
{
//…
string Id;
string Name;
string Address;
string Email;
//…
}
void SendEmail(Employee employee)
{
//.. uses Name and Email properties only
}
The above is a violation of ISP. The method SendEmail has no use of the class Employee, it only uses a Name and an Email to send out emails but is dependent on Employee class definition. This introduces unnecessary dependencies into the system, though it seems small at start. Now the SendEmail method can only be used for Employees and with nothing else; no reusability. Also, it has access to all the other features of Employee, without any requirements; security and isolation. Let’s rewrite it.
void SendEmail(string name, string email)
{
//.. sends email of whatever
}
Now the method does not care about any changes in the Employee class; dependency identified and isolated. It can be reused and is testable with anything, instead of just Employee. In short, don’t be misguided by the word Interface in ISP. It has its usage everywhere.
– D – Dependency Inversion Principle – DIP
“To exist, I did not depend upon my sister, and my sister not upon me. We both depended upon our parents”
Remember the example we discussed in SRP, where we introduced Database class into the EmployeeService.
class EmployeeService : IEmployeeService, ILeaveService
{
Database db = null;
public EmployeeService ()
{
//…
db = Database.Get(); // or a constructor etc. the EmployeeService is dependent upon Database
//..
}
Add(Employee emp)
{
//…
db.Add<Employee>(emp);
//..
}
}
The DIP dictates that:
No high-level modules (EmployeeService) should be dependent upon any low-level modules (Database), instead both should depend upon abstractions. And abstractions should not depend upon details, details should depend upon abstractions.
The EmployeeService here is a high-level module that is using, and dependent upon a low-level module, Database. This introduces a hidden dependency on the Database class. This also increases the coupling between EmployeeService and the Database. The client code using EmployeeService now must have access to the Database class definition, even though it’s not exposed to it and does not know, apparently, that Database class/ service/ factory/ interface exists.
Also note that it does not matter if, to get a Database instance, we use a singleton, factory, or a constructor. Inverting a dependency does not mean replacing its constructor with a service / factory/ singleton call, because then the dependency is just transformed into another class/ interface while remain hidden. One change in Database.Get, for example, could have unforeseen implications on the client code using the EmployeeService without knowing. This makes the code rigid and tightly coupled to details, difficult to test and almost impossible to reuse.
Let’s change it a bit.
class EmployeeService : IEmployeeService, ILeaveService
{
Database db = null;
public EmployeeService (Database database)
{
//…
db = database;
//..
}
Add(Employee emp)
{
//…
db.Add<Employee>(emp);
//..
}
//…
}
We have moved the Getting of Database to an argument in the constructor (because the scope of the db variable is class level). Now EmployeeService is not dependent upon the details of Database instantiation. This solves one problem but the EmployeeService is still dependent upon a low-level module (Database). Let’s change that:
IDatabase db = null;
public EmployeeService (IDatabase database)
{
//…
db = database;
//..
}
We have replaced the Database with an abstraction (IDatabase). EmployeeService does not depend, nor care about any details of Database anymore. It only cares about the abstraction IDatabase. The Database class will be implementing the IDatabase abstraction (depends upon an abstraction).
Now the actual database implementation can be replaced anytime (testing) with a mock or with any other database details, as per the requirements and the Service will not be affected.
We have covered, in some details, the SOLID design principles, with few examples to understand the underline problems and how those can be solved using these principles. As can be seen, most of the time, a SOLID principle is just common sense and not making STUPID mistakes in designs and giving the business requirements some thought.
The definition of the Single Responsibility principle is incorrect. The right definition is “a class should only have one reason to change”.
What you put as a definition is actually a consequence of SRP. In reality a class (in the context of OOP) should not have more than on responsibility, and that can is only possible if it does not have more than one reason to exist, change comes later. Same thing, different ways to say, in practice.
Example of Lsp looks for me like example of Isp. It solves problem of different behaviour of child class but with interface segregation. Sorry but still Lsp is not really clear. Everything else makes closer to understand solid, thanks for this post.