What are SOLID Principles?

SOLID design principles are a set of norms that help reduce dependencies in the software design process.

Intended to make designs easier to understand, maintain, and scale, SOLID principles allow developers to make changes to one part of the code without impacting the performance of other parts.

In the current volatile business environment, every developer should know and utilize these five SOLID principles:

1. Single Responsibility Principle (SRP)

SRP states that any class, module, component, or microservice should have only one responsibility or solve only one problem for any one part of the software's functionality. The principle makes it easy to develop, test, and maintain code while avoiding the unforeseen side effects of future changes.

For example, the checkout process in an e-commerce application will have many features such as order summary, shipping address, payment mode, payment details, etc. Instead of developing each feature as a separate entity, teams can use SRP to regroup the responsibilities of checkout into smaller entities. Such separation of concerns ensures low-level changes do not impact high-level business logic.

2. Open Closed Principle (OCP)

This principle allows software entities such as classes, modules, and functions to be easily extended but not modified. This means teams can extend a class's behavior without modifying it. OCP makes it easy for teams to write code that doesn't have to be modified every time the requirements change. By writing code that is easy to maintain and revise, teams can easily add additional functionality using abstractions.

Consider an e-commerce company that wants to introduce a new mode of payment. OCP allows the development team to add a new "payment" class without modifying the underlying code.

3. Liskov Substitution Principle (LSP)

Named after Barbara Liskov, who introduced this concept, LSP is simply an extension of the open-closed principle. It states that any derived class should allow for extending the base class without changing behavior. The principle helps avoid unexpected consequences of changes while eliminating the need to open a closed class for updates and extensions.

For instance, in an e-commerce payment scenario, customers can purchase using their credit card or a digital wallet. Under normal circumstances, the code will throw an exception if a user uses the card option. Using LSP, developers can add another class for payment and structure the class hierarchy in a way that does not break the application.

4. Interface Segregation Principle (ISP)

The general idea of an ISP is to have several smaller interfaces instead of one big, general-purpose interface. Such fine-grained client-specific interfaces allow developers to start with an existing interface and add new methods as needed. It also ensures clients are not forced to implement interfaces they do not use.

Consider an e-commerce company that has a web client for placing orders and an admin client for configuring stores and products. Keeping these interfaces isolated enables easier development of new features and changes. It also improves the understandability and maintainability of specific interfaces while allowing them to evolve separately over time.

5. Dependency Inversion Principle (DIP)

This design principle offers an easy way to decouple software modules. By empowering developers to focus on abstractions and not concretions, DIP ensures high-level modules do not depend upon low-level modules. DIP makes code more flexible, agile, and reusable when done right.

An e-commerce company that wants to change its payment gateway from PayPal to Apple Pay would need to make several changes to the underlying code. Teams would also have to test everything from scratch again. Using DIP, they can create an intermediate layer and wrap it around the payment gateway service. By abstracting the payment gateways, developers can make the required switch to Apple Pay – without impacting the code.