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

TL;DR: Don't over-generalize

Problems

• Speculative Design

• Complexity

• Over-Engineering

Solutions

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