Запах дизайна - Design smell

В компьютерное программирование, запахи дизайна представляют собой «конструкции в проекте, указывающие на нарушение основных принципов проектирования и негативно влияющие на качество проектирования».[1] Происхождение термина «дизайнерский запах» можно проследить до термина «запах кода "который был показан в книге Рефакторинг: улучшение дизайна существующего кода к Мартин Фаулер.[2]

Подробности

Разные авторы по-разному определяют слово «запах»:

  • Н. Моха и другие.: «Запах кода и дизайна - плохое решение повторяющихся проблем реализации и проектирования».[3]
  • Р. К. Мартин: «Запахи дизайна - это запах гниющего программного обеспечения».[4]
  • Фаулер: «Запахи - это определенные структуры в коде, которые предполагают (иногда кричат) о возможности рефакторинга».[2]

Запахи дизайна указывают на накопленный дизайнерский долг (один из важных аспектов технический долг ). Ошибки или нереализованные функции не считаются запахом дизайна. Запахи дизайна возникают из-за неправильных дизайнерских решений, которые делают дизайн хрупким и сложным в обслуживании. Хорошей практикой является выявление недостатков дизайна в программной системе и применение соответствующего рефакторинга для их устранения, чтобы избежать накопления технического долга.

Контекст (характеризуемый различными факторами, такими как рассматриваемая проблема, проектная экосистема и платформа) играет важную роль в принятии решения о том, следует ли рассматривать определенную структуру или решение как запах дизайна. Как правило, уместно жить с запахами дизайна из-за ограничений, налагаемых контекстом.

Общие дизайнерские запахи

  • Отсутствует абстракция[1] когда вместо создания абстракции используются группы данных или закодированные строки. Также известна как «примитивная одержимость». [2] и «скопления данных».[2]
  • Многогранная абстракция[1] когда на абстракцию возложено несколько обязанностей. Также известно как «злоупотребление концептуализацией».[5]
  • Повторяющаяся абстракция[1] когда две или более абстракций имеют одинаковые имена или реализации, или и то, и другое. Также известны как «альтернативные классы с разными интерфейсами».[2] и «повторяющиеся артефакты дизайна».[6]
  • Недостаточная инкапсуляция[1] когда заявленная доступность одного или нескольких членов абстракции более разрешительна, чем фактически требуется.
  • Неиспользуемая инкапсуляция[1] когда клиентский код использует явные проверки типа (с использованием связанных операторов if-else или switch, которые проверяют тип объекта) вместо использования вариации в типах, уже инкапсулированных в иерархии.
  • Сломанная модуляризация[1] когда данные и / или методы, которые в идеале должны были быть локализованы в одной абстракции, разделяются и распределяются по нескольким абстракциям.
  • Недостаточная модульность[1] когда существует абстракция, которая не была полностью разложена, и дальнейшая декомпозиция может уменьшить ее размер, сложность реализации или и то, и другое.
  • Круговая зависимость. Циклически зависимая модуляризация [1] когда две или более абстракций зависят друг от друга прямо или косвенно (создавая тесную связь между абстракциями). Также известны как «циклические зависимости».[7]. Циклическая иерархия [1] когда супертип в иерархии зависит от любого из его подтипов. Также известен как «циклы наследования / ссылок».[8]
  • Нефакторная иерархия[1] когда существует ненужное дублирование типов в иерархии.
  • Нарушенная иерархия[1] когда супертип и его подтип концептуально не разделяют отношения «IS-A», что приводит к нарушенной заменяемости. Также известно как «неправильное использование наследования».[9] и «неправильное применение IS A».[10]

Смотрите также

Рекомендации

  1. ^ а б c d е ж грамм час я j k л Гириш Сурьянараяна, Ганеш С.Г., Тушар Шарма (2014). «Рефакторинг для разработки программного обеспечения пахнет: Управление техническим долгом». Морган Кауфманн. ISBN  978-0128013977
  2. ^ а б c d е Фаулер, Мартин (1999). Рефакторинг. Улучшение дизайна существующего кода. Эддисон-Уэсли. ISBN  0-201-48567-2.
  3. ^ N. Moha, Y. Gueheneuc, L. Duchien и A. Le Meur. «Декор: метод определения и обнаружения запахов кода и дизайна». IEEE Trans. Софтв. Eng., 36 (1): 20–36, январь 2010 г.
  4. ^ Р. К. Мартин. Гибкая разработка программного обеспечения, принципы, шаблоны и практики. Аддисон-Уэсли, 2003.
  5. ^ Трифу А. "Автоматизированная реструктуризация объектно-ориентированного кода на основе стратегии". В материалах 7-го немецкого семинара по реинжинирингу программного обеспечения (WSR); 2005 г.
  6. ^ Сталь М. "Рефакторинг архитектуры программного обеспечения". Учебник на Международной конференции по объектно-ориентированному программированию, системам, языкам и приложениям (OOPSLA); 2007 г.
  7. ^ Пейдж-Джонс М. «Практическое руководство по проектированию структурированных систем». 2-е изд. Прентис Холл; 1988 г.
  8. ^ Сефика М, Вменяемый А, Кэмпбелл Р. «Мониторинг соответствия программной системы ее проектным моделям высокого уровня». В материалах 18-й международной конференции по разработке программного обеспечения, ICSE ‘96, Вашингтон, округ Колумбия; 1996. стр. 387–96.
  9. ^ Бадд Т. "Введение в объектно-ориентированное программирование". 3-е изд. Эддисон Уэсли; 2001 г.
  10. ^ Пейдж-Джонс М. «Основы объектно-ориентированного проектирования в UML». Эддисон-Уэсли Профессионал; 1999 г.