Дизайнерский запах
В компьютерном программировании — запах дизайна это структура в дизайне, которая указывает на нарушение фундаментальных принципов дизайна и может отрицательно повлиять на качество проекта. [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]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Перейти обратно: а б с д и ж г час я дж к л Гириш Сурьянараяна, Ганеш С.Г., Тушар Шарма (2014). «Рефакторинг для дизайна программного обеспечения: управление техническим долгом». Морган Кауфманн. ISBN 978-0128013977
- ^ Перейти обратно: а б с д и Фаулер, Мартин (1999). Рефакторинг. Улучшение дизайна существующего кода. Аддисон-Уэсли. ISBN 0-201-48567-2 .
- ^ Н. Моха, Ю. Генек, Л. Дюшин и А. Ле Мёр. «Декор: метод спецификации и обнаружения запахов кода и дизайна». IEEE Транс. Программное обеспечение Eng., 36(1):20–36, январь 2010 г.
- ^ RC Мартин. Гибкая разработка программного обеспечения, принципы, шаблоны и практики . Аддисон-Уэсли, 2003.
- ^ Трифу А. «Автоматическая реструктуризация объектно-ориентированного кода на основе стратегии». В материалах 7-го немецкого семинара по реинжинирингу программного обеспечения (WSR); 2005.
- ^ Сталь М. «Рефакторинг архитектуры программного обеспечения». Учебник на Международной конференции по объектно-ориентированному программированию, системам, языкам и приложениям (OOPSLA); 2007.
- ^ Пейдж-Джонс М. «Практическое руководство по проектированию структурированных систем». 2-е изд. Прентис Холл; 1988.
- ^ Сефика М., Сане А., Кэмпбелл Р.Х. «Контроль соответствия программной системы ее проектным моделям высокого уровня». В материалах 18-й международной конференции по разработке программного обеспечения, ICSE '96, Вашингтон, округ Колумбия; 1996. с. 387–96.
- ^ Бадд Т. «Введение в объектно-ориентированное программирование». 3-е изд. Эддисон Уэсли; 2001.
- ^ Пейдж-Джонс М. «Основы объектно-ориентированного проектирования в UML». Аддисон-Уэсли Профессионал; 1999.