Python has become one of the most popular programming languages due to its simplicity, readability, and versatility. However, as applications grow in complexity, maintaining code becomes increasingly challenging. This is where SOLID principles come into play. Initially coined by Robert C. Martin, SOLID is an acronym for five design principles that help developers create more maintainable, flexible, and scalable code. In this blog post, we'll explore each SOLID principle, provide examples of code not adhering to them, and demonstrate how to refactor the code to follow the tenets using Python programming.
Single Responsibility Principle (SRP):
The Single Responsibility Principle states that a class should have only one purpose to change. Let's take a hammer as an example. Hammers are great for driving nails into wood, right? But what if that same hammer suddenly had a sharp corner for sawing? It would be confusing and awkward to use.
Similarly, in coding, if a class meant for one job starts doing another unrelated job, it can make your code confusing and complicated to work with. That's why we stick to the Single Responsibility Principle - keeping each class focused on its job, just like keeping a hammer for hammering and a saw for sawing. Let's take a look at an example of code that violates this principle:
class Order:
def __init__(self, customer, product, quantity):
self.customer = customer
self.product = product
self.quantity = quantity
def calculate_total(self):
return self.product.price * self.quantity
def send_confirmation_email(self):
pass
In this example, the Order class manages orders and sends confirmation emails, violating the SRP. Let's refactor the code to adhere to the SRP:
class Order:
def __init__(self, customer, product, quantity):
self.customer = customer
self.product = product
self.quantity = quantity
def calculate_total(self):
return self.product.price * self.quantity
class EmailSender:
def send_confirmation_email(self, customer):
pass
By separating the responsibility of sending confirmation emails into its class EmailSender, we adhere to the SRP, making the codebase more straightforward to maintain and modify in the future.
Open/Closed Principle (OCP):
The Open/Closed Principle states that classes should be open for extension but closed for modification. Think of the Open/Closed Principle as designing a toy. When you create a toy, you want it to be fun to play with. But what if you could add new features to the toy without changing its original design? That's the idea behind the Open/Closed Principle.
Imagine you have a toy car. It's built to allow you to add new features, like attaching different accessories or upgrading its engine, without altering the car itself. This makes the toy more versatile and adaptable to new ideas, all while keeping its original design intact.
Similarly, in coding, the Open/Closed Principle suggests that classes should be open for extension. You can add new functionality but closed for modification, so you don't have to change their existing code. This makes your code more flexible and easier to maintain in the long run. Let's examine code that violates this principle:
class Shape:
def __init__(self, type):
self.type = type
def area(self):
if self.type == "Rectangle":
pass
elif self.type == "Circle":
pass
In this example, if we want to add a new shape, we must modify the Shape class, violating the OCP. Let's refactor the code to adhere to the OCP:
class Shape:
def area(self):
pass
class Rectangle(Shape):
def __init__(self, width, height):
self.width = width
self.height = height
def area(self):
return self.width * self.height
class Circle(Shape):
def __init__(self, radius):
self.radius = radius
def area(self):
return 3.14 * self.radius * self.radius
By creating subclasses like Rectangle and Circle that extend the behaviour of the Shape class, we adhere to the OCP, allowing for easy extension without modifying existing code.
Liskov Substitution Principle (LSP):
The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. Picture a recipe book. Let's say you have a basic recipe for making a cake. According to the Liskov Substitution Principle, if you have a fancier recipe for making the same type of cake, you should be able to use it interchangeably with the basic recipe without messing up the final result.
So, if you follow the fancier recipe precisely as written, using fancier ingredients or different techniques, you should still end up with a delicious cake. The key is that the new recipe keeps the basic recipe's fundamental rules and expectations.
In coding, this principle applies to classes and their subclasses. It means that you should be able to use a subclass wherever you'd use its superclass without causing errors or unexpected behaviour. Just like swapping out one recipe for another shouldn't ruin your cake, swapping out one class for its subclass shouldn't break your program. Let's see an example of code that violates this principle:
class Bird:
def fly(self):
pass
class Ostrich(Bird):
def fly(self):
raise NotImplementedError("Ostrich cannot fly")
def make_bird_fly(bird):
bird.fly()
ostrich = Ostrich()
make_bird_fly(ostrich)
In this example, although Ostrich is a subclass of Bird, it cannot fly, violating the LSP. Let's refactor the code to adhere to the LSP:
class Bird:
def fly(self):
pass
class Sparrow(Bird):
def fly(self):
print("Sparrow flying")
class Ostrich(Bird):
def fly(self):
print("Ostrich cannot fly")
def make_bird_fly(bird):
bird.fly()
ostrich = Ostrich()
make_bird_fly(ostrich)
By ensuring that Ostrich provides a valid implementation of the fly method, we adhere to the LSP, allowing objects of Ostrich to be used interchangeably with objects of Bird without affecting the correctness of the program.
Interface Segregation Principle (ISP):
The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use. Imagine you're at a buffet and only interested in a few specific dishes. The Interface Segregation Principle allows you to pick and choose only the dishes you want without taking everything on the buffet table.
So, if you only like salad and dessert, you should be free to take a plate with only some dishes on it. Similarly, in coding, if you're a client of a class and only need to use specific methods or features, you shouldn't be forced to depend on a large interface with many methods you won't use.
Instead, just like at the buffet, you should be able to pick and choose only the interface parts you need. This keeps things clean and efficient and avoids unnecessary dependencies in your code. Let's examine code that violates this principle:
class Printer:
def print_document(self, document):
pass
def scan_document(self, document):
pass
class SimplePrinter(Printer):
def print_document(self, document):
print("Printing document")
class AdvancedPrinter(Printer):
def print_document(self, document):
print("Printing document")
def scan_document(self, document):
print("Scanning document")
In this example, clients of the SimplePrinter class are forced to depend on the scan_document method, even though they don't need it, violating the ISP. Let's refactor the code to adhere to the ISP:
class Printer:
def print_document(self, document):
pass
class SimplePrinter(Printer):
def print_document(self, document):
print("Printing document")
class Scanner:
def scan_document(self, document):
pass
class AdvancedPrinter(Printer, Scanner):
def print_document(self, document):
print("Printing document")
def scan_document(self, document):
print("Scanning document")
By segregating interfaces into smaller, more focused ones like Printer and Scanner, we adhere to the ISP, allowing clients to depend only on the needed methods.
Dependency Inversion Principle (DIP):
The Dependency Inversion Principle states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions. Let's envision building a house. In traditional methods, the roof relies directly on the walls for support, creating a direct dependency. But what if we flip that concept?
Imagine the roof and walls both depend on a sturdy framework, abstracting away their direct dependency on each other. This way, changes to one component won't directly impact the other, fostering flexibility and easier maintenance.
In coding, this translates to high-level modules (like the roof) not relying on low-level modules (like the walls). Instead, both depend on a common abstraction, like the framework. This promotes a more adaptable and manageable codebase, where changes in one part don't cascade throughout the system. Let's examine code that violates this principle:
class EmailSender:
def send_email(self, customer, message):
pass
class OrderProcessor:
def __init__(self):
self.email_sender = EmailSender()
def process_order(self, order):
self.email_sender.send_email(order.customer, "Your order has been processed")
In this example, the OrderProcessor class directly depends on the concrete implementation EmailSender, violating the DIP. Let's refactor the code to adhere to the DIP:
class EmailSender:
def send_email(self, customer, message):
pass
class OrderProcessor:
def __init__(self, email_sender):
self.email_sender = email_sender
In conclusion, object-oriented design principles are like guiding stars illuminating the path toward cleaner, more maintainable code. By adhering to these principles – ensuring classes have single responsibilities, making code open for extension but closed for modification, segregating interfaces, or inverting dependencies – developers can craft robust, flexible, and easier-to-understand software.
A well-designed building stands the test of time, as does well-designed code. By embracing these principles, developers can create software that meets current needs and adapt gracefully to future challenges. So, let's keep these principles in mind as we architect our digital creations, ensuring they stand tall amidst the ever-changing landscape of technology.
