Что такое анти-паттерн?

Я изучаю паттерны и анти-паттерны. У меня есть четкое представление о паттернах, но я не получаю анти-паттернов. Определения из интернета и Википедии меня очень смущают.

может кто-нибудь объяснить мне простыми словами, что анти-паттерн? Какова же цель? Что они делают? Это плохо или хорошо?

12 129
class-design terminology design-patterns anti-patterns ooad

12 ответов:

анти-шаблоны есть определенные закономерности в разработке программного обеспечения, которые считаются плохими методами программирования.

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

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

например:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

в приведенном выше примере есть объект, который делает все. В объектно-ориентированном программировании было бы предпочтительно иметь четко определенные обязанности для разных объектов, чтобы код был менее связанным и в конечном итоге больше ремонтопригодный:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

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

167

всякий раз, когда я слышу об анти-паттернах, я вспоминаю другой термин, а именно. Дизайн запах.

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

есть много дизайн запахи классифицируются на основе нарушения принципов проектирования:

абстракция пахнет

Отсутствует Абстракция: этот запах возникает, когда вместо создания класса или интерфейса используются сгустки данных или закодированные строки.

Императив Абстракции: этот запах возникает, когда работа превращается в класс.

Неполное Отведение: этот запах возникает, когда абстракция не поддерживает дополнительные или взаимосвязанные методы полностью.

Многогранной Абстракции:

Ненужные Абстракции: этот запах возникает, когда абстракция, которая на самом деле не нужна (и, таким образом, можно было бы избежать) вводится в дизайн программного обеспечения.

Неиспользованных Абстракции: этот запах возникает, когда абстракция не используется (или не используется напрямую или не доступен).

Дублировать Абстракции: этот запах возникает, когда две или более абстракций имеют одинаковые имена или одинаковые реализации или оба.

инкапсуляция пахнет

Дефицит Инкапсуляции: этот запах возникает, когда объявленная доступность одного или нескольких членов абстракции более разрешительна, чем требуется на самом деле.

Дырявый Инкапсуляции: этот запах возникает, когда абстракция "раскрывает" или "пропускает" детали реализации через свой открытый интерфейс.

Отсутствует Инкапсуляция: этот запах возникает, когда варианты реализации не инкапсулированы в абстракции или иерархии.

Неэксплуатируемых Инкапсуляции: этот запах возникает, когда клиентский код использует явные проверки типа (с помощью цепных операторов if-else или switch, которые проверяют тип объекта) вместо использования изменение типов, уже инкапсулированных в иерархии.

модуляризации пахнет

Сломанной Конструкцией:

Недостаточная Модульность: этот запах возникает, когда существует абстракция, которая не была полностью разложена, и a дальнейшая декомпозиция может уменьшить ее размер, сложность реализации или и то, и другое.

Циклически-Зависимой Конструкцией:

Hub-Like Modularization: этот запах возникает, когда абстракция имеет зависимости (как входящие, так и исходящие) с большим количеством других абстракции.

иерархия пахнет

Отсутствует Иерархия: этот запах возникает, когда сегмент кода использует условную логику (обычно в сочетании с "помеченными типами") для явного управления изменениями в поведении, где иерархия могла быть создана и использована для инкапсуляции этих изменений.

Ненужный Иерархии: этот запах возникает, когда вся иерархия наследования не нужна, что указывает на то, что наследование было применено без необходимости для конкретного контекста проектирования.

Иерархия Unfactored: этот запах возникает, когда есть ненужное дублирование между типами в иерархии.

Широкий Иерархии: этот запах возникает, когда иерархия наследования "слишком" широка, указывая, что промежуточные типы могут отсутствовать.

Спекулятивная Иерархия: этот запах возникает, когда один или несколько типов в иерархии предоставлено спекулятивно (т. е. на основе воображаемых потребностей, а не реальных потребностей).

Глубокая Иерархия: этот запах возникает, когда иерархия наследования "чрезмерно" глубока.

Мятежный Иерархии: этот запах возникает, когда подтип отвергает методы, предусмотренные его супертипа(ов).

Нарушена Иерархия: этот запах возникает, когда супертип и его подтип концептуально не разделяют "IS-A" отношения, приводящие к нарушенной заменяемости.

Иерархия Многолучевости: этот запах возникает, когда подтип наследует как напрямую, так и косвенно от супертипа, что приводит к ненужным путям наследования в иерархии.

Циклическая Иерархия:

вышеуказанные определение и классификация описаны в "рефакторинг для разработки программного обеспечения запахи: управление технической задолженности". Можно найти еще несколько соответствующих ресурсов здесь.

36

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

пример:" шаблон "будет использовать функцию для повторного использования кода," анти-шаблон " будет использовать copy-paste для того же самого. Оба решают одну и ту же проблему, но использование функции обычно приводит к более удобочитаемому и поддерживаемому коду, чем копирование-вставка.

30

анти-паттерн-это способ не решать проблему. Но это еще не все: это также способ, который часто можно увидеть в попытках решить проблему.

15

Если вы действительно хотите изучать антипаттерны, получите книгу Антимоделей (ISBN-13: 978-0471197133).

в нем они определяют "антипаттерн-это литературная форма, которая описывает обычно встречающееся решение проблемы, которое порождает явно негативные последствия."

Итак, если это плохая практика программирования, но не обычная-ограниченная одним приложением, одной компанией или одним программистом, она не соответствует" шаблонной " части Антипаттера определение.

9

распространенный способ сделать беспорядок. Например, класс god/kitchensink (делает все).

7

An анти-шаблон является дополнением шаблон. Анти-шаблон-это шаблонное решение, которое вы не должны использовать в определенной ситуации.

6

с шаблон, an анти-шаблон также является шаблоном и повторяемым способом решения определенной проблемы, но неоптимальным и неэффективным способом.

6

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

4

сегодня исследователи и практики в области разработки программного обеспечения часто используют термины" анти-паттерн "и" запах " взаимозаменяемо. Однако они концептуально не совпадают. В статье Википедии анти-паттерна говорится, что анти-паттерн отличается от плохой практики или плохой идеи по крайней мере двумя факторами. Анти-паттерн

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

это ясно указывает на то, что анти-паттерн выбирается в убеждении, что это хорошее решение (как образец) в представленной проблемы; однако, это приносит больше обязательств, чем преимуществ. С другой стороны, запах-это просто плохая практика, что негативно влияет на качество программной системы. Например, Singleton-это класс anti-pattern и God (или недостаточно Modularization) - это дизайнерский запах.

3

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

2

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

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

вы можете проверить вопрос что такого плохого в синглетах? чтобы лучше понять различные мнения по этому поводу.

0