Что такое анти-шаблон?

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

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

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() {}
}

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


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

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

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

абстракция запахи!--8-->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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


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

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

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


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


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


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


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


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

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

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


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


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

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

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