SOLID principles

The SOLID principles are five design principles in object-oriented programming that help create more maintainable, flexible, and scalable software. They were introduced by Robert C. Martin (also known as “Uncle Bob”) and are widely used as guidelines to achieve clean, high-quality code.

Here’s an overview of each of the SOLID principles:

1. Single Responsibility Principle (SRP)

• Definition: A class should have one, and only one, reason to change. This means a class should only have one job or responsibility.
• Purpose: Ensures that each class focuses on a single responsibility, making the codebase easier to understand, test, and maintain.
• Example:
  
  Java

  // Violates SRP: This class handles both user data and notification logic public class User { public void saveUser() { /* save user logic */ } public void sendNotification() { /* notification logic */ } } // Follows SRP: Separates user logic from notification logic public class User { public void saveUser() { /* save user logic */ } } public class NotificationService { public void sendNotification() { /* notification logic */ } }

  1 2 3 4 5 6 7 8 9 10 11 12 13

  // Violates SRP: This class handles both user data and notification logic public class User {   public void saveUser() { /* save user logic */ }   public void sendNotification() { /* notification logic */ } }   // Follows SRP: Separates user logic from notification logic public class User {   public void saveUser() { /* save user logic */ } } public class NotificationService {   public void sendNotification() { /* notification logic */ } }

2. Open/Closed Principle (OCP)

• Definition: Software entities (classes, modules, functions) should be open for extension but closed for modification. This means that the behavior of a module should be extendable without modifying its source code.
• Purpose: Promotes flexibility in the codebase by allowing new functionality to be added without altering existing code, thus minimizing the risk of introducing bugs.
• Example:
  
  Java

  // Violates OCP: Modification required for adding new account types public class AccountService { public double getInterestRate(String accountType) { if ("SAVINGS".equals(accountType)) return 4.5; else if ("CURRENT".equals(accountType)) return 3.5; return 0; } } // Follows OCP: Extends functionality through inheritance public interface Account { double getInterestRate(); } public class SavingsAccount implements Account { public double getInterestRate() { return 4.5; } } public class CurrentAccount implements Account { public double getInterestRate() { return 3.5; } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  // Violates OCP: Modification required for adding new account types public class AccountService {   public double getInterestRate(String accountType) {       if ("SAVINGS".equals(accountType)) return 4.5;       else if ("CURRENT".equals(accountType)) return 3.5;       return 0;   } }   // Follows OCP: Extends functionality through inheritance public interface Account {   double getInterestRate(); } public class SavingsAccount implements Account {   public double getInterestRate() { return 4.5; } } public class CurrentAccount implements Account {   public double getInterestRate() { return 3.5; } }

3. Liskov Substitution Principle (LSP)

• Definition: Subtypes must be substitutable for their base types. Essentially, objects of a superclass should be replaceable with objects of a subclass without affecting the functionality of the program.
• Purpose: Ensures that derived classes extend the base class without changing its behavior, making code more predictable and reliable.
• Example:
  
  Java

  // Violates LSP: Square class changes behavior of setWidth and setHeight public class Rectangle { private int width; private int height; public void setWidth(int width) { this.width = width; } public void setHeight(int height) { this.height = height; } } public class Square extends Rectangle { @Override public void setWidth(int width) { this.setWidth(width); this.setHeight(width); } @Override public void setHeight(int height) { this.setWidth(height); this.setHeight(height); } } // Follows LSP: Square class does not inherit from Rectangle, maintains integrity

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

  // Violates LSP: Square class changes behavior of setWidth and setHeight public class Rectangle {   private int width;   private int height;   public void setWidth(int width) { this.width = width; }   public void setHeight(int height) { this.height = height; } } public class Square extends Rectangle {   @Override   public void setWidth(int width) { this.setWidth(width); this.setHeight(width); }   @Override   public void setHeight(int height) { this.setWidth(height); this.setHeight(height); } }   // Follows LSP: Square class does not inherit from Rectangle, maintains integrity

4. Interface Segregation Principle (ISP)

• Definition: Clients should not be forced to implement interfaces they do not use. This means larger interfaces should be divided into smaller, more specific ones so that clients only need to know about the methods that are of interest to them.
• Purpose: Reduces the need for implementing unnecessary methods, keeping the code cleaner and more aligned with each class’s responsibilities.
• Example:
  
  Java

  // Violates ISP: Interface forces implementation of unrelated methods public interface Worker { void work(); void eat(); } public class RobotWorker implements Worker { public void work() { /* work logic */ } public void eat() { /* unnecessary for a robot */ } } // Follows ISP: Separate interfaces for distinct responsibilities public interface Workable { void work(); } public interface Eatable { void eat(); } public class RobotWorker implements Workable { public void work() { /* work logic */ } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  // Violates ISP: Interface forces implementation of unrelated methods public interface Worker {   void work();   void eat(); } public class RobotWorker implements Worker {   public void work() { /* work logic */ }   public void eat() { /* unnecessary for a robot */ } }   // Follows ISP: Separate interfaces for distinct responsibilities public interface Workable {   void work(); } public interface Eatable {   void eat(); } public class RobotWorker implements Workable {   public void work() { /* work logic */ } }

5. Dependency Inversion Principle (DIP)

• Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.
• Purpose: Decouples high-level components from low-level ones, promoting a more modular and testable code structure.
• Example:
  
  // Violates DIP: Class directly depends on a low-level implementation public class Keyboard { // Keyboard logic } public class Computer { private Keyboard keyboard; public Computer() { this.keyboard = new Keyboard(); // tightly coupled } } // Follows DIP: Depends on an abstraction public interface InputDevice { // InputDevice logic } public class Keyboard implements InputDevice { // Keyboard logic } public class Computer { private InputDevice inputDevice; public Computer(InputDevice inputDevice) { this.inputDevice = inputDevice; } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  // Violates DIP: Class directly depends on a low-level implementation public class Keyboard {   // Keyboard logic } public class Computer {   private Keyboard keyboard;   public Computer() {       this.keyboard = new Keyboard(); // tightly coupled   } }   // Follows DIP: Depends on an abstraction public interface InputDevice {   // InputDevice logic } public class Keyboard implements InputDevice {   // Keyboard logic } public class Computer {   private InputDevice inputDevice;   public Computer(InputDevice inputDevice) {       this.inputDevice = inputDevice;   } }

Summary of SOLID Principles

• Single Responsibility Principle (SRP): One class, one responsibility.
• Open/Closed Principle (OCP): Open for extension, closed for modification.
• Liskov Substitution Principle (LSP): Subtypes should be replaceable for their base types.
• Interface Segregation Principle (ISP): No client should be forced to depend on methods it does not use.
• Dependency Inversion Principle (DIP): Depend on abstractions, not on concretions.

Benefits of Using SOLID Principles

1. Easier Maintenance and Scalability: Code is easier to update and extend.
2. Improved Testability: Components are decoupled, making unit testing straightforward.
3. Flexibility and Modularity: Easier to adapt to changing requirements and reuse components.
4. Enhanced Readability: The code is more understandable and logically organized.