Каковы контрольные признаки плохого объектно-ориентированного дизайна?

Ответ 1

То, что в основном торчит для меня, это " код пахнет".

В основном я чувствителен к вещам, которые противоречат "хорошей практике".

Вещи вроде:

• Способы, которые делают вещи, отличные от того, что вы думаете по имени (например: FileExists(), который молча удаляет файлы с нулевым байтом)

• Несколько чрезвычайно длинных методов (знак обертки объекта вокруг процедуры)

• Повторное использование операторов switch/case на том же перечисляемом элементе (знак подклассов, нуждающихся в извлечении)

• Множество переменных-членов, которые используются для обработки, а не для захвата состояния (может указывать на необходимость извлечения объекта метода)

• Класс, у которого много обязанностей (нарушение принципа Единой Репутация)

• Длинные цепи доступа к члену (это хорошо, это.что другое прекрасно, но my.very.long.chain.of.member.accesses.for.a.result является хрупким)

• Плохое присвоение классов

• Использование слишком большого количества шаблонов проектирования в небольшом пространстве

• Слишком сложно работать (переписывать функции, уже присутствующие в фреймворке или в другом месте в том же проекте)

• Плохая орфография (в любом месте) и грамматика (в комментариях) или комментарии, которые просто вводят в заблуждение

Ответ 2

Я бы сказал, что правило номер один для плохого дизайна OO (и да, я виноват в этом слишком много раз!):

• Классы, которые разбивают Single Принцип ответственности (SRP) и выполнить слишком много действий.

Далее следуют:

• Слишком много наследования вместо состав, то есть классы, которые вытекают из подтипа они бесплатно получают функциональность. Использовать композицию над наследованием.

Ответ 3

Проверьте это. Это потрясающе.

Плохие запахи: http://c2.com/xp/CodeSmell.html

Его не специфично для объектно-ориентированного программирования, но он охватывает много бит. Приветствия.

Ответ 4

Невозможно выполнить unit test правильно.

Ответ 5

Анти-шаблоны

Анти-шаблоны разработки программного обеспечения

• Инверсия абстракции: не выставлять реализованные функции, необходимые пользователям, чтобы они повторно реализовывали ее с помощью функций более высокого уровня.
• Неоднозначная точка зрения: представление модели (обычно OOAD) без указания ее точки зрения
• Большой шар грязи: система без узнаваемой структуры
• Blob: Обобщение объекта God от объектно-ориентированного дизайна
• Газ factory: излишне сложный дизайн
• Входной клик: невозможность указать и реализовать обработку, возможно, недопустимого ввода
• Интерфейс вздутия: создание интерфейса настолько мощным, что его чрезвычайно сложно реализовать
• Магическая кнопка: логика реализации кодирования непосредственно внутри кода интерфейса, без использования абстракции.
• Расовая опасность: Неспособность увидеть последствия различных порядков событий.
• Решение для железных дорог: предлагаемое решение, которое пока плохое, является единственным доступным из-за плохой предвидения и негибкости в других областях дизайна
• Повторное соединение: введение ненужной зависимости объекта
• Система дымохода: едва ремонтируемая сборка плохо связанных компонентов.
• Старилизованная схема: схема базы данных, содержащая таблицы с двумя целями для нормализации и использования данных datamart

Объектно-ориентированный дизайн анти-шаблонов

• Анемическая модель домена: использование модели домена без какой-либо бизнес-логики, которая не является ООП, поскольку каждый объект должен иметь как атрибуты, так и поведение
• BaseBean: унаследовать функциональность из класса утилит, а не делегировать ему
• Вызов супер: требует, чтобы подклассы вызывали переопределенный метод суперкласса
• Проблема с окружным эллипсом: подтипирование переменных-типов на основе значений-подтипов
• Сбой пустого подкласса: создание класса, который не выполняет "Empty Subclass Test", по-своему отличаться от производного от него класса без изменений
• Объект God: концентрация слишком большого числа функций в одной части дизайна (класса)
• Объект cesspool: Повторное использование объектов, состояние которых не соответствует (возможно, неявному) контракту для повторного использования
• Оргинация объектов: невозможность правильно инкапсулировать объекты, позволяющие неограниченный доступ к их внутренним функциям
• Полтергейсты: объекты, единственной целью которых является передача информации другому объекту.
• Последовательная связь: класс, который требует, чтобы его методы вызывались в определенном порядке
• Синглтонит: чрезмерное использование одноэлементного рисунка
• Еще один бесполезный слой: добавление ненужных слоев в программу, библиотеку или фреймворк. Это стало популярным после первой книги по шаблонам программирования.
• Проблема Yo-yo: структура (например, наследования), которую трудно понять из-за чрезмерной фрагментации.

Ответ 6

Этот вопрос делает предположение, что объектно-ориентированный означает хороший дизайн. Бывают случаи, когда другой подход гораздо более уместен.

Ответ 7

Один запах - это объекты, имеющие жесткие зависимости/ссылки на другие объекты, которые не являются частью их иерархии естественных объектов или состав, относящийся к домену.

Пример: Скажем, у вас симуляция города. Если объект Person имеет свойство NearestPostOffice, у вас, вероятно, есть проблемы.

Ответ 8

Одна вещь, которую мне не нравится видеть, - это базовый класс, сбрасывающий себя в производный класс. Когда вы видите это, вы знаете, что у вас проблемы.

Другие примеры могут быть:

• Чрезмерное использование операторов switch
• Производные классы, которые переопределяют все

Ответ 9

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

Конечно, если вы прочтете мой последний вопрос, вы можете понять, почему я немного измучен.

Ключевая проблема с ООП заключается в том, что он не делает очевидным, что граф построения объекта должен быть независимым от вашего графика вызовов.

Как только вы исправите эту проблему, ООП действительно начинает иметь смысл. Проблема в том, что очень немногие команды знают об этом шаблоне проектирования.

Ответ 10

В длинном методе разделы, окруженные #region/#endregion, почти в каждом случае, который я видел, этот код можно легко извлечь в новый метод или необходимо каким-то образом реорганизовать.

Слишком сложные деревья наследования, где подклассы имеют разные вещи и только касательно связаны друг с другом.

Нарушение DRY - подклассов, каждый из которых переопределяет базовый метод почти точно так же, с незначительным изменением. Пример. Недавно я работал над некоторым кодом, в котором каждый из подклассов переопределял базовый метод и где единственным отличием был тест типа ( "x is ThisType" vs "x is ThatType" ). Я реализовал метод в базе, который взял общий тип T, который затем использовался в тесте. Затем каждый ребенок мог вызвать базовую реализацию, передав тип, с которым он хотел протестировать. Это обрезало около 30 строк кода из каждого из 8 разных дочерних классов.

Ответ 11

Вот несколько:

• Циклические зависимости
• Вы с свойством XYZ базового класса не были защищены/закрыты
• Вы хотите, чтобы ваш язык поддерживал множественное наследование

Ответ 12

Найдите программиста, который имеет опыт работы с базой кода. Попросите их объяснить, как что-то работает.

Если они говорят, что "эта функция вызывает эту функцию", их код является процедурным.

Если они говорят, что "этот класс взаимодействует с этим классом", их код - OO.

Ответ 13

Дублирующий код = Код, который делает то же самое... Я думаю, по моему опыту, это самая большая ошибка, которая может возникнуть при проектировании OO.

Ответ 14

У вас есть все объекты, наследующие некоторый базовый класс утилиты, чтобы вы могли вызвать свои методы утилиты, не набирая так много кода.

Ответ 15

Объекты хорошо создают газильон из них - плохой дизайн OO.

Ответ 16

Ниже перечислены наиболее характерные особенности плохого дизайна:

• Жесткость
• Хрупкость
• неподвижность

Взгляните на Принцип инверсии зависимостей