Code Smell 136 — Классы только с одним подклассом

Обобщать и предвидеть будущее — это хорошо (опять же).

TL;DR: не обобщайте слишком много

Проблемы

• Спекулятивный дизайн
• Сложность
• Чрезмерная инженерия

Решения

1. Удалите абстрактный класс, пока не получите больше примеров

Контекст

В прошлом программисты говорили нам проектировать с учетом изменений.

В настоящее время мы продолжаем следовать научному методу.

Всякий раз, когда мы находим дубликат, мы удаляем его.

Не раньше, чем.

Не с интерфейсами, не с классами.

Образец кода

Неправильный

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

Обнаружение

[Х] Автоматически

Для наших линтеров это очень просто, так как они могут отследить эту ошибку во время компиляции.

Исключения

Некоторые фреймворки создают абстрактный класс в качестве заполнителя для построения наших моделей на их основе.

Подклассификация никогда не должна быть нашим первым вариантом.

Более элегантным решением было бы объявить интерфейс, так как он менее связан.

Теги

• Над дизайном

связи

Заключение

Нам нужно ждать абстракций, а не быть творческими и спекулятивными.

Кредиты

Фото автора Бенджамин Дэвис на Unsplash

Написание класса без его контракта было бы похоже на создание инженерного компонента (электрическая схема, микросхема СБИС (очень большая интеграция), мост, двигатель…) без спецификации. Ни один профессиональный инженер даже не подумал бы об этой идее.

Бертран Мейер

Эта статья является частью серии CodeSmell.