Demystifying SOLID Principles

Imagine SOLID as a set of guidelines to build strong, adaptable software. Here’s a breakdown of each letter:

• S - Single Responsibility Principle: A class should be like a single-purpose tool in your toolbox. It shouldn’t try to do too many things at once. If you find a class trying to juggle multiple tasks, it might be time to break it down into more specialized tools.

   class FileReader:
       def read_file(self, filename):
           # read file logic here
           pass

   class DataProcessor:
       def process_data(self, data):
           # data processing logic here
           pass

• O - Open/Closed Principle: Think of this like building a house with an extension in mind. The core structure should stay solid, but you should be able to add features (like a sunroom) without having to tear down the whole thing. Your code should be easy to extend with new functionalities without needing major rewrites.

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

• L - Liskov Substitution Principle: This principle is like having interchangeable parts. Imagine knights in shining armor - any knight’s armor (subclass) should fit a jousting horse (superclass) without problems. In code, subclasses (more specific types) should seamlessly step in for their base classes (general types) without causing errors.

class Bird:
  def fly(self):
    pass

class Sparrow(Bird):
    def fly(self):
        print("Sparrow flying")

def make_bird_fly(bird):
    bird.fly()

sparrow = Sparrow()
make_bird_fly(sparrow)  # Should print "Sparrow flying"

• I - Interface Segregation Principle: Instead of a giant, overwhelming remote control for every single feature in your entertainment system, imagine having smaller, dedicated remotes for the TV, sound system, and so on. Clients (parts of your code that use other parts) shouldn’t be forced to rely on features they don’t need. Break down large interfaces into smaller, more specific ones for cleaner and more focused interactions.

class Printer:
  def print(self, document):
    pass

class Scanner:
  def scan(self, document):
    pass

class Copier(Printer, Scanner):
    pass

• D - Dependency Inversion Principle: High-level modules, like the CEO of a company, shouldn’t be reliant on the low-level employees (like the plumbers). Both should rely on clear guidelines (abstractions). These guidelines shouldn’t dictate every tiny detail (low-level); instead, the specifics should follow the broader principles. This way, changes at a lower level don’t cause havoc at the top.

class Database:
    def save(self, data):
        pass

class SomeService:
    def __init__(self, database):
        self.database = database

    def save_data(self, data):
        self.database.save(data)

db = Database()
service = SomeService(db)

By following these SOLID principles, you’re essentially building software that’s flexible, easier to maintain, and less prone to breaking down when changes are needed – kind of like a well-designed and adaptable building!

Cheers,

Sim