DEV Community: Skylar V. Allen

SOLID Principles In 2025 In Practice With Python And UML Examples

Skylar V. Allen — Thu, 28 Aug 2025 20:04:53 +0000

Because your future self deserves better code reviews.

Why Should You Care About SOLID in 2025?

Let’s be real: most developers nod politely when SOLID comes up, then continue writing 500-line classes that smell worse than week-old fried eggs.

Here’s the thing: SOLID isn’t about pleasing your CS professor. It’s about writing code that your future self won’t want to rage-quit from after a single bugfix. Bad code means frustration, late nights, and way too much coffee.

SOLID is a language that senior devs use to communicate across years of maintenance. When you see it in a project, you don’t need to crawl line by line like some code archaeologist digging through ruins. Instead, you can predict the system’s behavior, understand responsibilities, and trust that classes aren’t hiding surprises like a clown in a sewer drain. Follow it, and you can read code like a map. Ignore it, and you're wandering blind through spaghetti caves.

What is SOLID (for the two people who missed the party)?

SOLID is an acronym for five object-oriented design principles coined by Uncle Bob Martin back when 2000s were still a thing:

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)

Each principle is simple in words, but game-changing in practice. Let’s walk through them with Python and UML examples, and see why your future code reviewers will thank you.

🪓 Single Responsibility Principle (SRP)

One job, one class. Don’t be that developer who mixes logging, DB writes, and business logic in one method.

Why it matters

If a class does too many things, every change risks breaking unrelated behavior. It’s like wiring your home’s electricity, plumbing, and gas through the same pipe - one adjustment and the whole house either floods, burns, or explodes.

Bad Example

Here’s a FileManager class that thinks it’s Batman: reads files, writes them, compresses them, and even appends greetings:

from pathlib import Path
from zipfile import ZipFile


class FileManager:
    def __init__(self, file_path: str):
        self.path = Path(file_path)

    def read(self) -> str:
        return self.path.read_text('utf-8')

    def write(self, content: str):
        self.path.write_text(content, 'utf-8')

    def compress(self):
        with ZipFile(self.path.with_suffix('.zip'), mode='w') as file:
            file.write(self.path)

    def add_greeting(self, content: str) -> str:
        return content + '\nHello world!'


if __name__ == '__main__':
    file_path = 'data.txt'
    file_manager = FileManager(file_path)
    content = file_manager.add_greeting(file_manager.read())
    file_manager.write(content)
    file_manager.compress()

What’s wrong?

Although the usage looks easy, every time you need to tweak compression, you risk breaking file writing. Change greetings? Oops, now compression fails

Good Example

Split responsibilities. Each class does one job, cleanly.

from pathlib import Path
from zipfile import ZipFile

DEFAULT_ENCODING = 'utf-8'


class FileReader:
    def __init__(self, file_path: Path, encoding: str = DEFAULT_ENCODING):
        self.path = file_path
        self.encoding = encoding

    def read(self) -> str:
        return self.path.read_text(self.encoding)


class FileWriter:
    def __init__(self, file_path: Path, encoding: str = DEFAULT_ENCODING):
        self.path = file_path
        self.encoding = encoding

    def write(self, content: str):
        self.path.write_text(content, self.encoding)


class FileCompressor:
    def __init__(self, file_path: Path):
        self.path = file_path

    def compress(self):
        with ZipFile(self.path.with_suffix('.zip'), mode='w') as file:
            file.write(self.path)


def add_greeting(self, content: str) -> str:
    return content + '\nHello world!'


if __name__ == '__main__':
    file_path = Path('data.txt')
    content = FileReader(file_path).read()
    FileWriter(file_path).write(add_greeting(content))
    FileCompressor(file_path).compress()

Although the call diagram looks a little trickier, now you can modify compression without touching greetings. Future you approves.

🧩 Open–Closed Principle (OCP)

Code should be open for extension, closed for modification. Like Netflix - adding new shows without rewriting the entire app.

Why it matters

If every new feature forces you to edit the same class, your code becomes a fragile Jenga tower. Add one more method, and boom - production outage.

Bad Example

The classic “God class of geometry”:

from math import pi


class Shape3D:
    def __init__(self, shape_type: str, **kwargs):
        self.shape_type = shape_type
        self.kwargs = kwargs

    def calculate_parallelepiped_volume(self):
        return self.kwargs['w'] * self.kwargs['h'] * self.kwargs['l']

    def calculate_sphere_volume(self):
        return 3 / 4 * pi * self.kwargs['r'] ** 3

    def calculate_cone_volume(self):
        return 1 / 3 * pi * self.kwargs['r'] ** 2 * self.kwargs['h']

    def volume(self) -> float:
        if self.shape_type == 'parallelepiped':
            return self.calculate_parallelepiped_volume()
        if self.shape_type == 'sphere':
            return self.calculate_sphere_volume()
        if self.shape_type == 'cone':
            return self.calculate_cone_volume()
        # Add more ifs forever
        raise ValueError


if __name__ == '__main__':
    print(Shape3D('parallelepiped', w=1.0, h=2.0, l=3.0).volume())
    print(Shape3D('sphere', r=3.5).volume())
    print(Shape3D('cone', r=3.5, h=2.0).volume())

Every time you add a new shape, you hack this class. Here, we are not extending; we are modifying. This violates OCP.

Good Example

Make a common base class, extend it with new shapes.

from abc import ABC, abstractmethod
from math import pi


class Shape3D(ABC):
    @abstractmethod
    def volume(self) -> float:
        raise NotImplementedError


class Parallelepiped(Shape3D):
    def __init__(self, w: float, h: float, l: float):
        self.w, self.h, self.l = w, h, l

    def volume(self):
        return self.w * self.h * self.l


class Sphere(Shape3D):
    def __init__(self, r: float):
        self.r = r

    def volume(self):
        return 3 / 4 * pi * self.r ** 3


class Cone(Shape3D):
    def __init__(self, r: float, h: float):
        self.r, self.h = r, h

    def volume(self):
        return 1 / 3 * pi * self.r ** 2 * self.h


if __name__ == '__main__':
    print(Parallelepiped(w=1.0, h=2.0, l=3.0).volume())
    print(Sphere(r=3.5).volume())
    print(Cone(r=3.5, h=2.0).volume())

Want a Torus? Just new subclass. No if-hell required, no edits of old code. Clean. Extensible. Chef’s kiss.

🤔 Another Discussable Example of OCP Violation

Here’s a class that offers multiple hard-coded greeting methods:

class GreetingContainer:
    def __init__(self, name: str):
        self.name = name

    def hi_greet(self):
        print("Hi, " + self.name)

    def hey_greet(self):
        print("Hey, " + self.name)

    def hello_greet(self):
        print("Hello, " + self.name)

At first glance this looks fine: we’re not deleting or altering existing methods, we’re just adding new ones. Technically, we’re extending the class. But here’s the catch: clients using this class must know exactly which method to call, and the interface keeps bloating. This design is brittle - new greetings mean more methods and more places in the code that have to be aware of them. You can argue it’s not a direct OCP violation, but it drifts into LSP territory: instances of GreetingContainer can’t be treated uniformly, since behavior depends on which method you pick (we will discuss it a little later).

🦆 Liskov Substitution Principle (LSP)

If code expects an object of some type, any subclass should be usable without nasty surprises. A subclass that breaks this promise isn’t an extension - it’s a landmine disguised as a feature.

Why it matters

Subclasses must be replaceable with their children without breaking stuff. Violate this, and you’ll create runtime landmines.

Bad example

class Bird:
    def fly(self):
        return "The bird is flying"

    def walk(self):
        return "The bird is walking"


class Duck(Bird):
    def fly(self):
        return "The duck is flying"

    def walk(self):
        return "The duck is walking"


class Penguin(Bird):
    def fly(self):
        raise AttributeError("Penguins cannot fly:(")

    def walk(self):
        return "The penguin is walking"

Penguins do exist, but they break LSP here. Anywhere you expect a Bird, the substitution fails and the design no longer guarantees consistent behavior.

Good example

Split behaviors:

class FlyingBird:
    def fly(self):
        return "The bird is flying"


class WalkingBird:
    def walk(self):
        return "The bird is walking"


class Duck(FlyingBird, WalkingBird):
    def fly(self):
        return "The duck is flying"

    def walk(self):
        return "The duck is walking"


class Penguin(WalkingBird):
    def walk(self):
        return "The penguin is walking"

Now penguins waddle safely. Ducks still fly. Everyone’s happy. No runtime betrayals.

☝️ Good Example of a greeter from the OCP topic

Define a base Greeter and extend it with new variants:

class Greeter:
    def __init__(self, name: str):
        self.name = name

    def greet(self):
        raise NotImplementedError


class HiGreeter(Greeter):
    def greet(self):
        print("Hi, " + self.name)


class HeyGreeter(Greeter):
    def greet(self):
        print("Hey, " + self.name)


class HelloGreeter(Greeter):
    def greet(self):
        print("Hello, " + self.name)

This design is cleaner: the interface stays stable (greet()), new greetings are real extensions, and polymorphism works. Clients don’t care how the greeting is produced - they just call greet(). And the real benefit: we can swap one Greeter for another and remain confident the code behaves as expected, without digging into implementation details - because we followed OCP and LSP. That’s the spirit of predictable, maintainable design.

For the nerds, the formal definition of this principle is:

🔌 Interface Segregation Principle (ISP)

Don’t force a class to implement methods it doesn’t need. Otherwise you’re just padding the code with dead weight.

Why it matters

Clients shouldn’t be forced to implement methods they don’t need. If your interface has eat() and sleep(), but a robot only needs charge(), you’re designing like it’s 1999. Formally: many small, focused interfaces are always better than one bloated interface that forces irrelevant obligations.

Bad example

from abc import ABC, abstractmethod


class IEmployee(ABC):
    @abstractmethod
    def work(self):
        pass

    @abstractmethod
    def eat(self):
        pass

    @abstractmethod
    def sleep(self):
        pass


class Programmer(IEmployee):
    def work(self):
        print("Programmer programs programs")

    def eat(self):
        print("Programmer eats pizza")

    def sleep(self):
        print("Programmer falls asleep at 2 AM")


class Android(IEmployee):
    def work(self):
        print("Android moves boxes")

    def eat(self):
        raise NotImplementedError("Android doesn't eat, it's a machine")

    def sleep(self):
        raise NotImplementedError("Android doesn't sleep, it's a machine")

Good example

Split interfaces:

from abc import ABC, abstractmethod


class IEmployee(ABC):
    @abstractmethod
    def work(self):
        pass


class IHuman(ABC):
    @abstractmethod
    def eat(self):
        pass

    @abstractmethod
    def sleep(self):
        pass


class IMachine:
    @abstractmethod
    def charge(self):
        pass


class Programmer(IEmployee, IHuman):
    def work(self):
        print("Programmer programs programs")

    def eat(self):
        print("Programmer eats pizza")

    def sleep(self):
        print("Programmer falls asleep at 2 AM")


class Android(IEmployee, IMachine):
    def work(self):
        print("Android moves boxes")

    def charge(self):
        print("Android charges, wait for 3 hours")

Now humans eat, robots charge. No unnecessary code. Interfaces are lean, not bloated.

Note: In Python, what we call an interface is usually represented with abc.ABC (Abstract Base Classes) or, in more modern code, with typing.Protocol. Both approaches allow you to declare required methods without providing concrete implementations. The key difference: ABC enforces inheritance (you must subclass it), while Protocol enables structural subtyping - any class that implements the required methods automatically matches the interface without explicit inheritance. You’ll also often see the convention of prefixing interfaces with I (like IEmployee) to distinguish them from concrete classes. While not enforced by the language, it’s a readability convention borrowed from other ecosystems (C#, Java) and helps developers immediately recognize intent.

🏗 Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations. Otherwise, your code is welded to a single library or vendor like shackles you’ll never escape from.

Why it matters

If your service directly imports boto3, good luck swapping S3 for HDFS, GCS, or even MinIO. From a formal perspective, this creates a tight coupling to a specific implementation rather than an abstraction, which severely limits extensibility and portability. Vendor lock-in = pain, and even a simple architectural decision - like supporting both on-prem HDFS and cloud object storage - suddenly requires massive rewrites.

Bad example

import boto3


class DistributedFileSystem:
    def __init__(self):
        self.client = boto3.client('s3')

    def read_file(path: str) -> bytes:
        data = self.client.get_object(Key=path)
        return data['Body'].read()

    def write_file(path: str, file: bytes):
        self.client.put_object(Body=file, Key=path)

Direct AWS dependency. Migrating to another cloud = rewrite.

Good example

Abstract it:

from abc import ABC, abstractmethod

import boto3


class DistributedFileSystem(ABC):
    @abstractmethod
    def read_file(path: str) -> bytes:
        pass

    @abstractmethod
    def write_file(path: str, file: bytes):
        pass


class BotoS3Client(DistributedFileSystem):
    def __init__(self):
        self.client = boto3.client('s3')

    def read_file(path: str) -> bytes:
        data = self.client.get_object(Key=path)
        return data['Body'].read()

    def write_file(path: str, file: bytes):
        self.client.put_object(Body=file, Key=path)


class HDFSClient(DistributedFileSystem): ...

Now you can switch storage backends without rewriting business logic. Future-proof and vendor-agnostic.

Final Thoughts: SOLID ≠ Religion, But It Saves Your Sanity

In 2025, frameworks evolve, clouds change, AI tools promise to “replace us”, but the pain of bad code is eternal.

SOLID isn’t dogma - it’s the difference between code that scales with your project and code nobody wants to work with.

Use SOLID not because Uncle Bob said so, but because your future self (and your team) will actually enjoy working with you.

👉 What do you think - are SOLID principles still relevant today, or do you prefer chaos-driven development?

💡 Stay in touch with me if you liked this article:

⭐ GitHub → for code, projects, and experiments
🔗 LinkedIn → for thoughts, articles, and networking

Mastering Python Script Scheduling: Pitfalls and Solutions

Skylar V. Allen — Sat, 23 Sep 2023 18:20:57 +0000

This article is about pitfalls, solutions, and what I've come to in scheduling Python scripts.

Imagine the following case: periodically, you have to execute updating SQLs using ORM models from your codebase with intermediate processing. For example, you want to detect inactive users by side factors like actions they've taken or not taken within a certain time frame once per day and mark them as inactive. This scenario often occurs in data-driven applications where you need to maintain the integrity and accuracy of your data.

Or a different one,

Every Monday at 10 AM your script must send internal reports on Slack to every manager about their employees' non-compliant Key Performance Indicators. This scenario is a common requirement in organizations striving to monitor and improve performance across various teams and departments.

What could go wrong?

Async code
If your codebase contains asynchronous parts that you'd like to reuse, you need to consider async support. I wouldn't recommend relying solely on the standard asyncio.run approach because you'll forfeit the advantages of asynchrony, and your code will operate like regular synchronous code.

Concurrent execution
If you have more than one job, you'll have to deal with parallel job execution. However, a common issue that arises is time shifting, as the scheduler may need to wait until one job finishes before it can move on to the next. This can potentially lead to delays in executions, especially when jobs have varying runtimes or when you have many jobs.

Resource leakage
There are different ways to start jobs, like using separate Python threads, individual processes, or event loops. The choice of initiation method can have a significant impact on CPU and memory utilization when you have a whole lot of jobs.

Restart intolerance
Inability to be resistant to reboots without affecting job intervals. In other words, after reboot, you get a time shift because of interrupting clocking. For example, you have a job whose interval is 3 hours. After 2 hours of clocking the CI/CD pipeline rebuilt the image and recreated the container to update the code because you pushed new commits. If the scheduler starts clocking right from the start, you'll get 2 hours of clocking before the reboot, and 3 after. So, in this case, the interval between executions is 5 hours and you have a significant time shift. Sometimes it might be critical.

Duplicate parallel executions
If the execution time of a job is more than an interval between executions or it varies, you may easily get a situation when the scheduler starts new executions of the job before the previous execution ends. It leads to job multiplication, resource leakage, and even a critical system shutdown due to overload. This case must be considered if you have short intervals or long-running jobs.

Localization
If you have a need to execute jobs at different times by different time zones on different days, it might be tricky to configure. For example, one job must be executed at 11 AM by New York on Monday only, a different one at 5 PM by Berlin on weekends, and the last one every 3 hours starting by Tokio on Friday only.

So, a lot could go wrong:)

Approaches

Let's look at possible ways to overcome pitfalls in order of their effectiveness.

Schedule Python lib

Schedule is the most basic scheduler for Python and the first one that you'll find if start googling.

It looks interesting, but the main disadvantage of this lib is that it's not designed to really use it somewhere. According to the official documentation:

You should probably look somewhere else if you need:

Job persistence (remember schedule between restarts)

Exact timing (sub-second precision execution)

Concurrent execution (multiple threads)

Localization (workdays or holidays)

Schedule does not account for the time it takes for the job function to execute.

Anyway, let's look at an example, pros and cons for further comparison.

import schedule
import time

def job():
    print("I'm working...")

schedule.every().day.at("10:30").do(job)

while True:
    schedule.run_pending()
    time.sleep(1)

Pros

Simple

Cons

No async code support
No concurrent execution
Restart intolerance
No localization

Cron Unix utility

Cron is the most popular general-purpose scheduler in the world. This scheduler is universal and starts jobs as a shell command. Take note that Cron starts a separate process for every job and this may take a lot of system resources.

Here you need a crontab file:

# m h dom mon dow user  command
*/30 * * * *      /usr/local/bin/python /path/to/the/script.py >> /var/log/cron.log 2>&1

In turn, the script can contain whatever your heart desires:

if __name__ == "__main__":
    print("Whatever your heart desires")

Pros

Concurrent execution
Versatility

Cons

No async code support
Resource leakage
Restart intolerance
Duplicate parallel executions
No localization

Regta Python utility

Regta is a scheduling tool designed with these pitfalls in mind especially for Python. The key advantage is that it has async, multithreading, and multiprocessing support just like restart tolerance.

from regta import async_job, Period

@async_job(Period().on.sunday.at("18:35").by("Asia/Almaty"))
async def my_async_job():
    pass  # Do some stuff here

To run it use regta run command.

Pros

Async code support
Concurrent execution
Restart tolerance
Localization

Cons

No strong community

Summary

When it comes to scheduling Python programs, the first option, Schedule, may not be the most suitable choice for solving real-world problems. Instead, consider the following points:

For internal automation tasks that involve various programming languages and CLI tools, Cron stands as a robust choice.

If your automation needs are focused on Python exclusively, Regta emerges as a compelling option, offering a wealth of Python-specific optimizations. Give it a try, and feel free to share your thoughts in the comments 🙌

DEV Community: Skylar V. Allen

SOLID Principles In 2025 In Practice With Python And UML Examples

Why Should You Care About SOLID in 2025?

What is SOLID (for the two people who missed the party)?

🪓 Single Responsibility Principle (SRP)

Why it matters

Bad Example

Good Example

🧩 Open–Closed Principle (OCP)

Why it matters

Bad Example

Good Example

🤔 Another Discussable Example of OCP Violation

🦆 Liskov Substitution Principle (LSP)

Why it matters

Bad example

Good example

☝️ Good Example of a greeter from the OCP topic

🔌 Interface Segregation Principle (ISP)

Why it matters

Bad example

Good example

🏗 Dependency Inversion Principle (DIP)

Why it matters

Bad example

Good example

Final Thoughts: SOLID ≠ Religion, But It Saves Your Sanity

Mastering Python Script Scheduling: Pitfalls and Solutions

What could go wrong?

Approaches

Schedule Python lib

Cron Unix utility

Regta Python utility

Summary

Useful links