SOLID Principles
SOLID Principles are a set of 5 software design principles introduced by Robert C. Martin (also known as Uncle Bob) to help improve the scalability, maintainability, and comprehensibility of code in object-oriented software development. SOLID stands for five core principles:
- 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)
1. Single Responsibility Principle (SRP)
The Single Responsibility Principle states that a class (or module) should have only one reason to change, meaning that each class should be responsible for only one task. This makes the code easier to maintain and extend.
Example: Suppose you have an Invoice class that manages invoice details and also prints the invoice. If you change how invoices are printed, you would have to modify the Invoice class, which could affect other parts of the system. To follow SRP, you can separate the printing responsibility into a different class, such as InvoicePrinter.
class Invoice:
def __init__(self, amount):
self.amount = amount
class InvoicePrinter:
def print_invoice(self, invoice):
print(f"Invoice amount: {invoice.amount}")
In this example, the Invoice class only manages the invoice information, while the task of printing invoices is handled by the InvoicePrinter class.
2. Open/Closed Principle (OCP)
The Open/Closed Principle says that a class should be open for extension but closed for modification. This means you should be able to extend the behavior of a class without modifying its existing code.
Example: Suppose you have a Shape class and subclasses like Circle and Rectangle. Instead of modifying the Shape class every time you add a new shape, you can extend it by inheritance.
class Shape:
def area(self):
pass
class Circle(Shape):
def __init__(self, radius):
self.radius = radius
def area(self):
return 3.14 * self.radius * self.radius
class Rectangle(Shape):
def __init__(self, width, height):
self.width = width
self.height = height
def area(self):
return self.width * self.height
When you need to add a new shape, you can simply create a new class instead of modifying the Shape class.
3. Liskov Substitution Principle (LSP)
The Liskov Substitution Principle states that objects of a subclass should be able to replace objects of the superclass without altering the correctness of the program. This means that subclasses must honor the behavior of the parent class.
Example: Suppose you have a Bird class and a subclass Penguin. If the Bird class has a fly() method, but penguins cannot fly, this violates the LSP. A better approach would be to separate the flying behavior from the Bird class and create a separate subclass for flying birds.
class Bird:
def eat(self):
print("Eating food")
class FlyingBird(Bird):
def fly(self):
print("Flying")
class Penguin(Bird):
pass # Penguins don't fly
4. Interface Segregation Principle (ISP)
The Interface Segregation Principle states that you should create smaller, more specific interfaces rather than one large interface with many functions. This prevents classes from being forced to implement methods they don’t need.
Example: Suppose you have a Worker interface with methods work() and eat(). If a class only needs to work but doesn’t need to eat, forcing it to implement the eat() method is unreasonable. You can separate the interfaces into smaller ones.
class Workable:
def work(self):
pass
class Eatable:
def eat(self):
pass
class Worker(Workable, Eatable):
def work(self):
print("Working")
def eat(self):
print("Eating")
5. Dependency Inversion Principle (DIP)
The Dependency Inversion Principle states that high-level classes should not depend on low-level classes. Both should depend on abstractions (interfaces or abstract classes). This helps make the code more flexible and easier to maintain.
Example: Suppose you have an Order class that creates a PaymentService object. Instead of making the Order class directly depend on PaymentService, you can create an interface PaymentProcessor and have Order depend on the interface.
class PaymentProcessor:
def process_payment(self, amount):
pass
class CreditCardPayment(PaymentProcessor):
def process_payment(self, amount):
print(f"Processing credit card payment of {amount}")
class Order:
def __init__(self, payment_processor: PaymentProcessor):
self.payment_processor = payment_processor
def complete_order(self, amount):
self.payment_processor.process_payment(amount)
# Usage:
payment_service = CreditCardPayment()
order = Order(payment_service)
order.complete_order(100)
Here, the Order class doesn’t depend on a specific type of payment. It depends on the PaymentProcessor interface, allowing you to change or add payment types without modifying the Order class.
Conclusion:
SOLID is an important set of principles that helps build software that is easy to maintain, extend, and reduces dependencies between classes. By applying these principles, the code becomes cleaner, more understandable, and easier to modify when adding new features.
