Being generic and foreseeing the future is good (again).
TL;DR: Don't over-generalize
Problems
Speculative Design
Complexity
Over-Engineering
Solutions
- Remove the abstract class until you get more examples
Context
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
Wrong
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
Right
class Boss(object):
def __init__(self, name):
self.name = name
# Bosses are concrete and can change mood
Detection
[X] Automatic
This is very easy for our linters since they can trace this error at compile time.
Exceptions
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.
Tags
- Over Design
Relations
Conclusion
We need to wait for abstractions and not be creative and speculative.
Credits
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)