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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

Капсулирование запахов

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

Leaky Encapsulation: Leaky Encapsulation: Этот запах возникает, когда абстракция «раскрывает» или «пропускает» детали реализации через открытый интерфейс.

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

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

Модуляризация запахов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, если это плохая практика программирования, но не распространенная, ограниченная одним приложением, одной компанией или одним программистом, она не соответствует части «Шаблон» в определении AntiPattern.

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

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

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

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

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

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

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

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

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

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

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

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