Действительно ли это является вонючим кодом, чтобы иметь пустые классы посреди иерархии классов?
Да. Из документации [отмечают, что это от более старой версии документов, но она все еще применяется]:
реализация JSLint принимает объект опции, который позволяет Вам определять подмножество JavaScript, который приемлем для Вас. Также возможно установить те опции в источнике сценария.
спецификация опции может быть похожей на это:
/*jslint nomen: true, debug: true,
evil: false, vars: true */
спецификация опции запускается с/*jslint. Заметьте, что нет никакого пространства перед j. Спецификация содержит последовательность пар значение-имя, где имена являются опциями JSLint, и значения являются TRUE или FALSE. Спецификация опции имеет приоритет по объекту опции.
документация конкретно не упоминает это, но можно включить и отключить различные проверки всюду по коду с несколькими комментариями jslint (благодарит Dominic Mitchell).
существует полный список опций в документации .
6 ответов
В общем, пустые классы - это запах кода.
Я согласен, что ваши методы isLeaf или isBranch являются правильной альтернативой.
Они добавляют информацию об объектах , что очень полезно.
(Это потому, что в суперклассе вы не можете выразить, что подклассы являются «либо листом, либо ветвью».)
Два метода с противоположными результатами также могут рассматриваться как дублирование кода . 1248] Вы можете использовать только один ... Но я бы рекомендовал возвращать перечислимое значение LEAF или BRANCH.
Для меня использование тестов «is-a» в управлении потоком так же неприятно, как и использование переключателя / корпуса. В хорошем ОО-дизайне ни то, ни другое не требуется.
Да, иерархии глубокого наследования в любом случае являются запахом кода.
Да, определенно запах кода - не кодируйте эти пустые классы, если вы не готовы записать в них этот код. Подумайте о YAGNI (он вам не понадобится) - не делайте этого, если он вам уже не нужен.
Кроме того, рассматривали ли вы случаи, когда эти классы существуют только для предоставления абстрактных методов или для их группировки на основе возможностей в с точки зрения методов или свойств?
В таком случае, может, вам действительно нужны интерфейсы, а не дополнительные абстрактные классы?
Класс, не содержащий кода, определенно является запахом кода ....
Меня устраивает, если вы собираетесь добавить новые функции позже.
Но если нет, здесь обычно используется перечисление.
- Edit
Хотя я должен согласиться с Бер , что вам в любом случае не следует использовать «is-a».