Being generic and foreseeing the future is good (again).
TL;DR: Don't over-generalize
- 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 with interfaces, not with classes.
class Boss(object): def __init__(self, name): self.name = name class GoodBoss(Boss): def __init__(self, name): super().__init__(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): self.name = name # Bosses are concrete and can change mood
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.
This article is part of the CodeSmell Series.