SOLID-principles

Examples of SOLID principles compared to bad design

SOLID Principles is an acronym of five principles.

1. S - Single Responsibility Principle
2. O - Open/Closed Principle
3. L - Liskov’s Substitution Principle
4. I - Interface Segregation Principle
5. D -Dependency Inversion Principle

SRP = Single responsibility principle

Every class should have responsibility over a single part of the functionality and that responsibility should be entirely encapsulated by this class.

Example. Class Car has the following information:

• Model name, year of issue which should be from 2010 to 2019
• You can print details about a car object

bad design	good design
Car class contains properties and a method	A car itself cannot print. Create another class Printer with a method which takes Car object as a parameter

OCP = Open / closed principle

Classes should be open for extension, but closed for modification.

Example. Class Reporting has the following information:

• You can create report about a car object in both pdf and docx formats

bad design	good design
Reporting class contains property and a method PrintData which cosists of multiply if-else.	Make method PrintData virtual and create two derived classes to override this method

LSP = Liskov’s Substitution Principle

Derived classes should extend base classes not change it.

Example: Base class Vehicle contains two methods of calculating a rent of vehicle and getting information about it.
Classes Bus and Car inherit from Vehicle but there is no ability to rent a Bus.

bad design	good design
Trying to instantiate a list of Vehicle type and add both *Car and Bus objects to it will lead to error	Create two interfaces instead of class Vehicle and let Car implement both and Bus - only IVehicle

ISP = Interface Seggregation Principle

Classes should not depend on methods they do not use.

Example. Two classes with similar functionaly Bus and Car:

• You can print details about a vehicle
• You can add new car but not a new bus.

bad design	good design
Car and Bus classes implement IVehicle interface with two methods	You cannot add a new bus, so Bus class should not implement IVehicle interface. In this case divide IVehicle into two interfaces with different methods

DIP = Dependency Inversion Principle

High-level classes should not depend on low-level classes.

Example. Classes which can send notifications by e-mail.

bad design	good design
Class Email and Notification are associated with each other. Class Notification creates an instance of Email. What to do if there would be a need of WhatsApp and mobile phone notofications?	Create an interface IMessenger, make class Email implement it and create a field of this type in class Notification

+++ Dependency Injection