Code Smell 136 - Classes With just One Subclass

Play this article

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


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

# Bosses are concrete and can change mood


[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.