Why OOP Is Overkill in Python: Embrace the Function‑Bag Style

1. No Need for OOP

Example code shows that using classes and inheritance for simple URL handling adds unnecessary complexity.

class ApiClient:
    def __init__(self, root_url: str, session_cls: sessionmaker):
        self.root_url = root_url
        self.session_cls = session_cls

    def construct_url(self, entity: str) -> str:
        return f"{self.root_url}/v1/{entity}"

    def get_items(self, entity: str) -> List[Item]:
        resp = requests.get(self.construct_url(entity))
        resp.raise_for_status()
        return [Item(**n) for n in resp.json()["items"]]

    def save_items(self, entity: str) -> None:
        with scoped_session(self.session_cls) as session:
            session.add(self.get_items(entity))

class ClientA(ApiClient):
    def construct_url(self, entity: str) -> str:
        return f"{self.root_url}/{entity}"

class ClientB(ApiClient):
    def construct_url(self, entity: str) -> str:
        return f"{self.root_url}/a/special/place/{entity}"

client_a = ClientA("https://client-a", session_cls)
client_a.save_items("bars")

Using OOP here only to bind root_url and a sessionmaker to an object, while inheritance is used to vary URL construction, can be replaced by passing data and functions directly.

@dataclass
class Client:
    root_url: str
    url_layout: str

client_a = Client(
    root_url="https://client-a",
    url_layout="{root_url}/{entity}",
)

client_b = Client(
    root_url="https://client-b",
    url_layout="{root_url}/a/special/place/{entity}",
)

def construct_url(client: Client, entity: str) -> str:
    return client.url_layout.format(root_url=client.root_url, entity=entity)

def get_items(client: Client, entity: str) -> List[Item]:
    resp = requests.get(construct_url(client, entity))
    resp.raise_for_status()
    return [Item(**n) for n in resp.json()["items"]]

def save_items(client: Client, session_cls: session_cls, entity: str) -> None:
    with scoped_session(session_cls) as session:
        session.add(get_items(client, entity))

save_items(client_a, session_cls, "bars")

This functional "function‑bag" style reduces code size by about 10%, is easier to understand, and avoids unnecessary OOP constructs.

What about non‑pure functions? If you need to interact with the current datetime, APIs, databases, or other side effects, you can still write pure‑looking functions and use tools like freezegun or responses to mock those effects.

2. Exceptions

You may notice the use of @dataclass to record types; Python 3.5+ supports this without needing regular classes.

Subclassing Exception is fine; a simple hierarchy does not have to become overly complex.

Enums are also well‑suited for Python and can be used freely.

In rare cases you might create a highly useful type (e.g., pandas.DataFrame or sqlalchemy.Session), but generally avoid over‑engineering and stay humble.

3. Drawbacks of OOP

OOP encourages mutable state; the function‑bag approach discourages modifying arguments.

Objects often hide data behind methods, making it harder to share simple values across functions.

Mixing data and behavior can complicate serialization, which is important for modern REST APIs.

Deep inheritance hierarchies proliferate, leading to endless debates.

Overall, OOP adds little value for many tasks and can make code harder to read and maintain.

Reference: https://leontrolski.github.io/mostly-pointless.html