Why I Stopped Blindly Using Python Classes

For many years I wrote almost all my Python code using classes, believing that object‑oriented programming was the professional standard. After building APIs, automation scripts, and data pipelines, I realized that in most cases I didn’t need classes at all and that they sometimes reduced development efficiency.

Why we were obsessed with classes

Beginners are taught that classes provide clear, extensible code. We quickly learn __init__, inheritance, and encapsulation, and start building complex class hierarchies for every small feature. An example of the typical template I used:

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

As projects grew, the extra ceremony of classes made simple code convoluted and sometimes hid logic behind unnecessary abstraction.

What alternatives I use

Prefer functions

If a feature does not need to maintain state across calls, a plain function is sufficient:

def send_email(to, subject, body):
    # simple and obvious
    pass

This style is faster to read, test, and maintain.

Dataclass for data containers

When I only need to store data, Python’s @dataclass offers an elegant solution:

from dataclasses import dataclass

@dataclass
class User:
    name: str
    email: str

Code is more concise

Automatically generates __init__, __repr__, etc.

Lightweight and highly readable

I now use dataclasses for DTOs, configuration objects, or structured parameters.

Dictionary for lightweight state

Sometimes a plain dictionary is enough, especially when handling JSON, API responses, or configuration data:

user = {
    "name": "Alice",
    "email": "[email protected]"
}

Module as a singleton

To share state or utility functions across multiple places, a simple module works without the overhead of a singleton class:

# email_utils.py

def send_email(to, subject, body):
    pass

# elsewhere
import email_utils
email_utils.send_email(...)

This yields flat, clear code without instantiation.

Beware premature abstraction

The biggest problem with classes is that they often introduce abstraction before it is truly needed, leading to code that is harder to test, more verbose, and less "Pythonic".

Harder to mock or test ("Should I mock the class or its methods?")

More boilerplate

Violates Python’s philosophy of simplicity and readability

Leveraging Python’s built‑in simplicity often results in more robust code, especially for scripts, micro‑services, or ETL tasks where classes are over‑design.

When I still use classes

When inheritance or polymorphism is required

Developing graphical interfaces or games (e.g., PyQt, Pygame)

Using frameworks that expect class structures (e.g., Django, FastAPI)

Objects have frequently changing state combined with rich behavior

In everyday work—writing functions, scripts, or APIs—these situations are rare.

Case study: Refactoring a Slack notifier

Original class‑based implementation:

class SlackNotifier:
    def __init__(self, webhook_url):
        self.webhook_url = webhook_url

    def send(self, message):
        # send message to Slack
        pass

Refactored function‑based version:

def send_slack_message(webhook_url, message):
    # directly send the message without instantiation
    pass

The new version is shorter, easier to test, and eliminates the need to instantiate an object before calling a method.

Final thought

Does this feature really need to be implemented with a class?

If the answer is no, try a simpler approach—your future self and teammates will thank you.