Факультет ИСиТ Вторник, 10.12.2019, 03:34
Приветствую Вас Гость | RSS
[ Персональный раздел · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
Факультет ИСиТ СыктГУ - Форум » Компьютеры / Интернет / Информационные системы и технологии » Программирование » Анти - паттерн (Или как не надо делать)
Анти - паттерн
eXceed Дата: Суббота, 11.10.2008, 14:29 | Сообщение # 1
Профессор
Группа: СуперАктив
Сообщений: 5252
Награды: 0
Статус: Offline
Решил оживить давно умерший раздел программирования.

Анти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем.

Термин происходит из информатики, из книги «Банды четырёх» Шаблоны проектирования, которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «шаблонами проектирования», и противоположными им являются «анти-паттерны». Частью хорошей практики программирования является избежание анти-паттернов.

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

Анти-паттерны в управлении разработкой ПО

* Дым и зеркала (Smoke and mirrors): Демонстрация того, как будут выглядеть ненаписанные функции (название происходит от двух излюбленных способов, которыми фокусники скрывают свои секреты).
* Раздувание ПО (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов.
* Функции для галочки: Превращение программы в конгломерат плохо реализованных и не связанных между собой функций (как правило, для того, чтобы заявить в рекламе, что функция есть).

Анти-паттерны в разработке ПО

* Инверсия абстракции (Abstraction inversion): Создание простых конструкций поверх сложных (спорный)
* Неопределённая точка зрения (Ambiguous viewpoint): Представление модели без спецификации её точки рассмотрения
* Большой комок грязи (Big ball of mud): Система с нераспознаваемой структурой
* Блоб (Blob): см. Божественный объект (God object)
* Бензиновая фабрика (Gas factory): Необязательная сложность дизайна
* Затычка на ввод данных (Input kludge): Забывчивость в спецификации и выполнении поддержки возможного неверного ввода
* Раздувание интерфейса (Interface bloat): Изготовление интерфейса очень мощным и очень трудным для осуществления
* Магическая кнопка (Magic pushbutton): Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, в системах типа Delphi это написание прикладной логики в обработчиках нажатий на кнопку.
* Перестыковка (компьютер) (Re-Coupling): Процесс внедрения ненужной зависимости
* Дымоход (Stovepipe system): Редко поддерживаемая сборка плохосвязанных компонентов
* Гонки (Race hazard, Race condition): Ошибка в определении последовательности различных порядков событий

Анти-паттерны в объектно-ориентированном программировании

* Базовый класс-утилита (BaseBean): Наследование функциональности из класса-утилиты вместо делегирования к нему
* Вызов предка (CallSuper): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.
* Ошибка пустого подкласса (Empty subclass failure): Создание класса (Perl), который не проходит «проверку пустоты подкласса» («Empty Subclass Test») из-за различного поведения по сравнению с классом, который наследуется от него без изменений
* Божественный объект (God object): Концентрация слишком большого количества функций в одиночной части дизайна (классе)
* Объектная клоака (Object cesspool): Переиспользование объектов, чьё состояние не удовлетворяет (возможно неявному) контракту переиспользования.
* Полтергейст (компьютер) (Poltergeist): Объекты, чьё единственное предназначение — передавать информацию другим объектам
* Проблема йо-йо (Yo-yo problem): Структура (например: наследования) которая тяжело понятна вследствие избыточной фрагментации
* Синглетонизм (Singletonitis): Избыточное использование паттерна синглетон

Анти-паттерны в программировании

* Ненужная сложность (Accidental complexity): Внесение ненужной сложности в решение
* Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между широко разделёнными частями системы
* Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных
* Слепая вера (Blind faith): Недостаточная проверка (a) корректности исправления ошибки или (b) результата работы подпрограммы
* Лодочный якорь (Boat anchor): Сохранение более не используемой части системы
* Активное ожидание (Busy spin): Потребление ресурсов ЦПУ (процессорного времени) во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать систему сообщений
* Кэшированный сбой (Caching failure): Забывать сбросить флаг ошибки после её обработки
* Проверка типа вместо интерфейса (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс
* Инерция кода (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы
* Кодирование путём исключения (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая
* Таинственный код (Cryptic code): Использование аббревиатур вместо полных (самоописывающих) имён
* Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации
* Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование.
* Поток лавы (Lava flow): Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия
* Магические числа (Magic numbers): Включение чисел в алгоритмы без объяснений
* Процедурный код (Procedural code): Когда другая парадигма является более подходящей
* Спагетти-код (Spaghetti code): Системы, чья структура редко понятна, особенно потому что структура кода используется неправильно
* Мыльный пузырь (Soap bubble): Класс, инициализированый мусором, максимально долго притворяется, что содержит какие-то данные.


bda-expert.ru — это система форумов, где можно общаться быстро и свободно, где любая точка зрения имеет право на жизнь.
 
eXceed Дата: Суббота, 11.10.2008, 14:29 | Сообщение # 2
Профессор
Группа: СуперАктив
Сообщений: 5252
Награды: 0
Статус: Offline
Методологические анти-паттерны

* Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений
* Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией
* Золотой молот (Golden hammer): Сильная уверенность в том, что любимое решение универсально применимо
* Фактор невероятности (Improbability factor): Предположение о невозможности того, что сработает известная ошибка
* Преждевременная оптимизация (Premature optimization): Оптимизация на основе недостаточной информации
* Изобретение колеса (Reinventing the wheel): Ошибка адаптации существующего решения
* Изобретение квадратного колеса (Reinventing the square wheel): Создание плохого решения, когда существует хорошее

Анти-паттерны управления конфигурацией

* Ад зависимостей (Dependency hell): Проблемы с версиями требующихся продуктов, особенно в системах UNIX/GNU/Linux
* DLL-ад (DLL hell): Проблемы с версиями, доступностью и увеличением количества DLL, особенно в Microsoft Windows.

Некоторые организационные анти-паттерны

* Аналитический паралич (Analysis paralysis): Выделение непропорционально больших усилий в фазе анализа проекта
* Дойная корова (Cash cow): Закрытый продукт, приносящий выгоду, часто ведёт к самоуспокоенности относительно новых продуктов
* Продолжительное устаревание (Continuous obsolescence): Выделение непропорционально больших усилий портированию системы в новые окружения
* Сваливание расходов (Cost migration): Перенос расходов на проект к уязвимому отделу или бизнес-партнёру
* Ползущий улучшизм (Creeping featurism): Добавление новых улучшений в ущерб качеству системы
* Разработка комитетом (Design by committee): Результат того, что имеется много содействующих разработке, но не имеется единого видения
* Эскалация обязательств (Escalation of commitment): Ошибка в неотзыве решения, когда доказана его вредность
* Я тебе это говорил (I told you so): Когда игнорируется предупреждение эксперта, являющееся оправданным
* Управление числами (Management by numbers): Уделение избыточного внимания численным критериям управления, когда они неважны или стоимость их получения слишком высока
* Драконовские меры (Management by perkele): Военный стиль управления без толерантности к диссидентству
* Управление грибами (Mushroom management): Удержание работников в неинформированном и занятом состоянии
* Расползание рамок (Scope creep): Дозволение рамкам проекта расти без должного контроля
* Замкнутость на продавце (Vendor lock-in): Изготовление системы, избыточно зависящей от внешнего поставляемого компонента
* Тёплое тело (Warm body): Человек, чей вклад в проект под сомнением, особенно если рассмотрен в панике
* Единственный знающий человек (Single head of knowledge): ЕЗЧ (SHOK) применим в том случае, когда единственная личность во всей организации контролирует жизненно-важную область ноу-хау или информации о внутренностях системы.
* Рыцарь на белом коне (Knight in shining armor): РНБК (KISA) происходит тогда, когда личность, которая не совершает ошибок, появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал/сделает и почему.

Шуточные анти-паттерны

Паблик Морозов: Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия. Название данного анти-паттерна — это каламбур, основанный на созвучии ключевого слова public (паблик), часто означающего открытый доступ к методам и полям класса в объектно-ориентированных языках программирования, и имени пионера-героя Павлика Морозова, известного тем, что он выдал своего отца-кулака.


bda-expert.ru — это система форумов, где можно общаться быстро и свободно, где любая точка зрения имеет право на жизнь.

Сообщение отредактировал eXceed - Суббота, 11.10.2008, 14:33
 
eXceed Дата: Суббота, 11.10.2008, 14:31 | Сообщение # 3
Профессор
Группа: СуперАктив
Сообщений: 5252
Награды: 0
Статус: Offline
Божественный объект (God object)

В объектно-ориентированном программировании, Божественный объект — это объект, который хранит в себе слишком много, или делает слишком много. Божественный объект является примером анти-паттерна.

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

Программа, основанная на Божественном объекте не следует этому подходу. Вместо этого, основная часть функциональности программы кодируется в одном объекте. Так как этот объект хранит большое количество данных и имеет много методов, его роль в программе становится «божественной»(всеобъемлющей).

Вместо того, чтобы общатся друг с другом непросредственно, другие объекты полагаются на Божественный объект. Так как на Божественный объект ссылается так много кода, его обслуживание становится гораздо сложнее.

Божественный объект — это объектно-ориентированный аналог отказа от использования подпрограмм в процедурном программировании, или использования слишком большого количества глобальных переменных для хранения информации о состоянии программы.

В то время, как создание Божественного объекта обычно считается плохой практикой программирования, они иногда создаются для работы при ограниченных ресурсах(например в микроконтроллерах), где прирост производительности важнее, чем поддерживаемость кода.


bda-expert.ru — это система форумов, где можно общаться быстро и свободно, где любая точка зрения имеет право на жизнь.
 
Факультет ИСиТ СыктГУ - Форум » Компьютеры / Интернет / Информационные системы и технологии » Программирование » Анти - паттерн (Или как не надо делать)
  • Страница 1 из 1
  • 1
Поиск:



Copyright bda-expert.ru © 2008-2019Хостинг от uCoz