SOLID programming principles have caught too much attention recently. There are many articles on SOLID principles that explain them superbly. My focus here would be to start with a simple example and apply these principles to see how we can shape up our code to match the Characteristics of a Good Software. I would show how we can achieve these characteristics by following the SOLID principles.
SOLID is an acronym for
- S – Single Responsibility Principle (SRP)
- O – Open/Closed Principle (OCP)
- L – Liskov Substitution Principle (LSP)
- I – Interface Segregation Principle (ISP)
- D – Dependency Inversion Principle (DIP)
Single Responsibility Principle (SRP)
Use SRP guidelines to write loosely coupled and highly cohesive software units which can be reused. This makes the software extendable and maintainable.
Classes and interfaces are basic units of a software. While writing a software we often overload a class with multiple responsibilities. As name suggests SRP states that a class should only perform one responsibility. Continue Reading
Open Closed Principle (OCP)
Take advantage of OCP to write highly extendable and maintainable software. Introduce new changes with minimal impact on the existing system. OCP seems to increase complexity of code due to abstraction levels it introduces. Embrace it pragmatically, find good candidates for OCP while designing software.
OCP states, our classes should be open for extension but closed for modification. Whenever we have to implement a change or add new functionality, instead of changing the existing class we should extend the functionality of existing class. Let’s try to understand with a scenario. Continue Reading
Liskov Substitution Principle (LSP)
OCP and LSP are very closely related. Implementing OCP would implicitly follow LSP in most of cases.
LSP states, If S is a subtype of T, any object of T can be substituted with an object of S leaving our software in stable state. Most of developers might know substitution already but let me explain a bit before moving forward. Consider a method void Notify (Campaign campaign). While calling this method we pass it the object of campaign Notify (new Campaign()); . Suppose our Campaign class has a child class called SummerCampaign then according to LSP calling this method as Notify (new SummerCampaign()); should also work for our software. Continue Reading
Interface Segregation Principle (ISP)
It’s useless to sell a frying pan to someone who doesn’t cook. Don’t give him a chance to say I don’t cook. In programming world we call it throwing NotImplemented Exception.
An interface defines the contract of an object. Contract means, the functions an object has to perform. When a class implements an interface, it has to provide implementation of all the functions defined in interface.
ISP states, Clients should not be forced to depend upon interfaces that they do not use.
Always create smallest possible interfaces rather interfaces with huge number of methods (contracts). Classes that implement interfaces should not be forced to provide implementation of methods which are not useful for them. Problem arises when any client using such an interface would end up having functions it does not use. Continue Reading
Dependency Inversion Principle(DIP)
Start implementing DIP in your code, it will drive you through other SOLID principles as well. Take advantage of DIP to write loosely coupled software modules/classes. This makes a software modules mockable and testable .
Dependency inversion principle has two parts.
- High level modules should not depend on low level modules directly, both should depend on abstractions.
- Abstractions should not depend on details, details should depend on abstractions. Continue Reading