Introduction
Writing clean, maintainable, and scalable code is crucial in software development. One of the most effective ways to achieve this is by adhering to the SOLID principles. These five design principles, introduced by Robert C. Martin (also known as Uncle Bob), provide a foundation for creating robust and flexible software systems. In this blog, we will explore each principle with real-time examples.
What are the SOLID Principles?
SOLID stands for Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov’s Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP). SOLID principles describe the set of rules and best practices to follow while designing a class structure.
Why the SOLID Principle?
SOLID principles make our code understandable, readable, and testable code that many developers can collaborate on. They help to build a system that can grow without becoming a tangled mess.
Prerequisites
- Basic Java Knowledge
- Object-Oriented Programming (OOP) Concepts
- Real-World Coding Experience
- Tools and Frameworks
1. Single Responsibility Principle (SRP)
The Single Responsibility principle states that a class should have only one reason to change, meaning it should have only one responsibility or job. When a class has multiple responsibilities then it is harder to maintain, change, and understand.
Example
// Bad Practices
class UserService {
public void authenticateUser(String username, String password) {
// Authentication logic
}
public void sendEmail(String userEmail, String message) {
// Email sending logic
}
}
// Good Practices
class AuthenticationService {
public void authenticateUser(String username, String password) {
// Authentication logic
}
}
class EmailService {
public void sendEmail(String userEmail, String message) {
// Email sending logic
}
}
In this example, UserService has two responsibilities: authenticateUser and sendEmail. A good practice is to have separate classes for authenticateUser and sendEmail.
2. Open/Closed Principle (OCP)
The Open/Closed Principle states that each class and module should be open for extension but closed for modification. That means we should be able to add new functionality to a class without changing that existing code.
Example
// Bad Practice
class AreaCalculatorBad {
public double calculateArea(Object shape) {
if (shape instanceof Circle) {
Circle circle = (Circle) shape;
return Math.PI * circle.radius * circle.radius;
} else if (shape instanceof Square) {
Square square = (Square) shape;
return square.side * square.side;
}
throw new IllegalArgumentException("Unknown shape");
}
}
// Good Practice
interface Shape {
double calculateArea();
}
class Circle implements Shape {
public double radius;
public Circle(double radius) {
this.radius = radius;
}
@Override
public double calculateArea() {
return Math.PI * radius * radius;
}
}
class Square implements Shape {
public double side;
public Square(double side) {
this.side = side;
}
@Override
public double calculateArea() {
return side * side;
}
}
class AreaCalculator {
public double calculateArea(Shape shape) {
return shape.calculateArea();
}
}
In this example AreaCalculatorBad class directly logic for each shape, adding a new shape requires modifying this class. Instead of modifying the Shape interface every time a new shape is added, we can extend it. This allows for the adding a new shape without changing the existing code.
3. Liskov Substitution Principle (LSP)
This Liskov Substitution Principle states that an object of Superclass(derived class) must be replaceable with an object of Subclass(parent class) without changing the correctness of the program.
Example
// Bad Design
class Bird {
void fly() {
System.out.println("Flying");
}
}
class Penguin extends Bird {
@Override
void fly() {
throw new RuntimeException("Penguins can't fly");
}
}
// Good Design
class Bird {
// Common bird behavior
}
class FlyingBird extends Bird {
void fly() {
System.out.println("Flying");
}
}
class NonFlyingBird extends Bird {
// Non-flying bird behavior
}
class Penguin extends NonFlyingBird {
// Penguin-specific behavior
}
In this example, the Penguin class violates the Liskov Substitution Principle; it doesn’t override the fly() method from the Parent Bird class.
4. Interface Segregation Principle (ISP)
The Interface Segregation Principle states that no clients should be forced to depend on methods it does not use. This principle supports creating smaller, more specific interfaces rather than large, general-purpose ones. It avoids bloated interfaces that lead to unnecessary dependencies.
Example
// Bad Design
interface Printer {
void print();
void scan();
}
class AllInOnePrinter implements Printer {
@Override
public void print() {
System.out.println("Printing");
}
@Override
public void scan() {
System.out.println("Scanning");
}
}
// Good Practice
interface Printer {
void print();
}
interface Scanner {
void scan();
}
class AllInOnePrinter implements Printer, Scanner {
@Override
public void print() {
System.out.println("Printing");
}
@Override
public void scan() {
System.out.println("Scanning");
}
}
In this example, Instead of a single Printer interface with methods for printing, scanning, and faxing, split it into smaller interfaces.
5. Dependency Inversion Principle (DIP)
The Dependency Inversion Principle suggests that high-level modules should not depend on low-level modules. Both should depend on abstraction. Also, abstraction depends on details and details should depend on abstraction.
Example
class User {
public void saveUser {
System.out.println("Create user successfully");
}
public void getUser() {
System.out.println("Getting all users");
}
}
class Info {
private User user;
// Constructor injection to follow DIP
public Info(User user) {
this.user = user;
}
public void getInfo() {
user.getUser();
}
}
In this example, by injecting User into Info we follow the Dependency Inversion Principle. Now Info class depends on the abstraction, and not the concrete implementation, making it easier to change the user information without affecting the Info.
Conclusion
Mastering the SOLID Principles is essential for writing clean, maintainable, and scalable software. by addressing this principle, we can create software that is easier to test, modify, and extend while minimizing the risk of bugs.
