DEV Community

Cover image for Code Smell 136 - Classes With just One Subclass
Maxi Contieri
Maxi Contieri

Posted on • Originally published at

Code Smell 136 - Classes With just One Subclass

Being generic and foreseeing the future is good (again).

TL;DR: Don't over-generalize


  • Speculative Design

  • Complexity

  • Over-Engineering


  1. Remove the abstract class until you get more examples


In the past, programmers told us to design for change.

Nowadays, We keep following the scientific method.

Whenever we find a duplication we remove it.

Not before.

Not with interfaces, not with classes.

Sample Code


class Boss(object):
    def __init__(self, name): = name 

class GoodBoss(Boss):
    def __init__(self, name):

# This is actually a very classification example
# Bosses should be immutable but can change their mood
# with constructive feedback
Enter fullscreen mode Exit fullscreen mode


class Boss(object):
    def __init__(self, name): = name  

# Bosses are concrete and can change mood
Enter fullscreen mode Exit fullscreen mode


[X] Automatic

This is very easy for our linters since they can trace this error at compile time.


Some frameworks create an abstract class as a placeholder to build our models over them.

Subclassifing should be never our first option.

A more elegant solution would be to declare an interface since it is less coupled.


  • Over Design



We need to wait for abstractions and not be creative and speculative.


Photo by Benjamin Davies on Unsplash

Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine...) without a spec. No professional engineer would even consider the idea.

Bertrand Meyer

This article is part of the CodeSmell Series.

Top comments (0)