Я изучаю шаблоны и анти-шаблоны. У меня есть четкое представление о моделях, но у меня нет анти-шаблонов. Определения из Интернета и Википедии меня путают много.
Может ли кто-нибудь объяснить мне простыми словами, что такое анти-шаблон? В чем цель? Что они делают? Это плохо или хорошо?
Анти-паттерны - это определенные паттерны в разработке программного обеспечения, которые считаются плохими практиками программирования.
В отличие от шаблонов проектирования, которые являются общими подходами к общим проблемам, которые были формализованы и обычно считаются хорошей практикой разработки, анти-шаблоны являются противоположностью и нежелательны.
Например, в объектно-ориентированном программировании идея состоит в том, чтобы разделить программное обеспечение на маленькие части, называемые объектами. Анти-паттерн в объектно-ориентированном программировании - это объект God, который выполняет множество функций, которые лучше разделить на разные объекты.
Например:
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", что приводит к нарушению замещаемости.
Многопутевая иерархия: этот запах возникает, когда подтип наследует как прямо, так и косвенно от супертипа, что приводит к ненужным путям наследования в иерархии.
Циклическая иерархия: этот запах возникает, когда супертип в иерархии зависит от любого из его подтипов.
Вышеупомянутое определение и классификация описаны в разделе "Рефакторинг запахов проектирования программного обеспечения: управление техническим долгом ". Некоторые более актуальные ресурсы можно найти здесь.
Образец - это идея о том, как решить проблему некоторого класса. Анти-шаблон - это идея о том, как не решить его, потому что реализация этой идеи приведет к плохому дизайну.
Пример: "шаблон" должен был бы использовать функцию повторного использования кода, "анти-шаблон" должен был бы использовать copy-paste для того же самого. Обе проблемы решают одну и ту же проблему, но использование функции обычно приводит к более легко читаемому и поддерживаемому коду, чем копирование.
Анти-паттерн - это способ не решить проблему. Но это еще не все: это также часто можно увидеть в попытках решить проблему.
Если вы действительно хотите изучить AntiPatterns, получите книгу AntiPatterns (ISBN-13: 978-0471197133).
В нем они определяют "AntiPattern - это литературная форма, которая описывает часто встречающееся решение проблемы, которая порождает явно отрицательные последствия".
Итак, если это плохая практика программирования, но не обычная, ограниченная одним приложением, одной компанией или одним программистом, она не соответствует части "Шаблон" определения AntiPattern.
Обычный способ сделать беспорядок. Например, класс god/kitchensink (делает все).
Как и в случае с шаблоном дизайна, анти-шаблон - это также шаблон и повторяемый способ решения определенной проблемы, но неоптимальным и неэффективным способом.
Анти-шаблон является дополнением шаблона дизайна. Анти-шаблон - это шаблонное решение, которое не следует использовать в определенной ситуации.
Интересно, что данный способ решения проблемы может быть как шаблоном, так и анти-шаблоном. Синглтон - яркий пример этого. Он появится в обоих наборах литературы.
Сегодня исследователи и специалисты в области программного обеспечения часто используют взаимозаменяемые термины "анти-шаблон" и "запах". Однако они концептуально не совпадают. Википедия в записи анти-шаблонов заявляет, что анти-шаблон отличается от плохой практики или плохой идеей по крайней мере двумя факторами. Анти-шаблон
"Обычно используемый процесс, структура или схема действий, которые, несмотря на первоначально представляя собой надлежащий и эффективный ответ на проблема, как правило, имеет более плохие последствия, чем положительные результаты".
Это ясно указывает на то, что анти-шаблон выбирается в убеждении, что это хорошее решение (как образец) для представленной проблемы; однако, это приносит больше обязательств, чем преимуществ. С другой стороны, запах - это просто плохая практика, которая отрицательно влияет на качество программной системы. Например, Singleton - это анти-шаблон, а класс God (или недостаточная модуляция) - это дизайнерский запах.
Анти-шаблоны являются обычным способом, когда люди склонны программировать неправильный путь или, по крайней мере, не очень хороший способ.
Любой шаблон проектирования, который приносит больше вреда, чем пользы для данной среды разработки программного обеспечения, будет рассматриваться как анти-шаблон.
Некоторые анти-паттерны очевидны, а некоторые нет. Например, Singleton, хотя многие считают это старым добрым шаблоном дизайна, но есть и другие, которые этого не делают.
Вы можете проверить вопрос Что такого плохого в синглетах? чтобы лучше понять различные мнения по этому поводу.
Как и в алгоритме, вы можете достичь решения, используя грубую силу, но вам придется заплатить много, если ситуация станет сложной.