Шаблоны проектирования, которых следует избегать [закрыто]

Question

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

Мой вопрос:Существуют ли другие шаблоны проектирования, которых следует избегать или использовать с большой осторожностью?

Answer 1

Закономерности сложны

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

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

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

Принципы важнее шаблонов

Использование шаблонов может показаться спорным, если они, очевидно, могут привести к чрезмерно разработанным и сложным решениям.Однако вместо этого программисту гораздо интереснее ознакомиться с методы и принципы проектирования это закладывает основу для большинства шаблонов.На самом деле один из моих в любимых книгах по "шаблонам проектирования" это подчеркивается повторяя, какие принципы применимы к рассматриваемому шаблону.Они достаточно просты, чтобы быть полезнее шаблонов с точки зрения релевантности.Некоторые из принципов достаточно общие, чтобы охватывать нечто большее, чем объектно-ориентированное программирование (ООП), такие как Принцип замещения Лискова, до тех пор, пока вы можете создавать модули своего кода.

Существует множество принципов проектирования, но те, которые описаны в первая глава книги GoF они весьма полезны для начала.

• Программируйте для "интерфейса", а не для "реализации". (Банда четырех, 1995:18)
• Отдавайте предпочтение "композиции объектов", а не "наследованию классов". (Банда четырех, 1995:20)

Позвольте им на некоторое время овладеть вами.Следует отметить, что когда GoF был написан интерфейс означает все, что является абстракцией (что также означает суперклассы), не путать с интерфейсом как типом в Java или C #.Второй принцип исходит из наблюдаемого чрезмерного использования наследования, которое заключается к сожалению, все еще распространено и сегодня.

Оттуда вы можете прочитать о ТВЕРДЫЕ принципы который был обнародован Робертом Сесилом Мартином (он же.Дядя Боб).Скотт Ханселман взял интервью у дяди Боба в подкаст об этих принципах:

• Sпринцип Внутренней ответственности
• Oпринцип Замкнутого пера
• Lпринцип Замещения искова
• Япринцип разделения поверхностей
• Dпринцип Инверсии Последовательности

Эти принципы - хорошее начало для ознакомления и обсуждения со своими коллегами.Вы можете обнаружить, что эти принципы переплетаются друг с другом и с другими процессами, такими как разделение интересов и внедрение зависимостей.После выполнения TDD на какое-то время вы также можете обнаружить, что эти принципы естественным образом проявляются на практике, поскольку вам нужно в какой-то степени следовать им, чтобы создавать изолированный и повторяемый модульные тесты.

Answer 2

Больше всего беспокоили самих авторов Design Patterns " Visitor " шаблон.

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

Альтернативное имя для " Visitor " шаблон - это " Multi-dispatch " ;, потому что шаблон Visitor - это то, с чем вы сталкиваетесь, когда хотите использовать однотипный язык OO для диспетчеризации, чтобы выбрать код для использования на основе типа двух (или более) разные объекты.

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

Во всяком случае, часто у вас получается что-то вроде этого:

interface IShape
{
    double intersectWith(Triangle t);
    double intersectWith(Rectangle r);
    double intersectWith(Circle c);
}

Проблема в том, что вы объединили все свои реализации " IShape " ;. Вы подразумевали, что всякий раз, когда вы хотите добавить новую фигуру в иерархию, вам нужно будет изменить все остальные & Quot; Shape & Quot; реализации тоже.

Иногда это правильный минимальный дизайн - но продумайте его. Ваш дизайн действительно требует от вас отправки двух типов? Готовы ли вы написать каждый комбинаторный взрыв мульти-методов?

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

interface IShape
{
    Area getArea();
}

class Area
{
    public double intersectWith(Area otherArea);
    ...
}

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

Answer 3

Singletons - класс, использующий singleton X, имеет зависимость, которую трудно увидеть и которую трудно выделить для тестирования.

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

См. Синглтоны - это патологические лжецы .

Answer 4

Я считаю, что шаблон шаблонного метода в целом является очень опасным шаблоном.

• Часто он использует вашу иерархию наследования по "неправильным причинам".
• Базовые классы имеют тенденцию быть заваленными всевозможным неэрелированным кодом.
• Это вынуждает вас блокировать дизайн, часто довольно рано в процессе разработки.(Преждевременная блокировка во многих случаях)
• Изменить это на более позднем этапе становится все труднее и труднее.

Answer 5

Я не думаю, что вам следует избегать Design Patterns (DP), и я не думаю, что вы должны заставлять себя использовать DP при планировании своей архитектуры. Мы должны использовать ПЛ только тогда, когда они естественным образом возникают из нашего планирования.

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

Одна вещь, которую мы также не должны делать, это рассматривать DP как неизменную сущность, мы должны адаптировать шаблон к нашим потребностям.

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

Answer 6

Я думаю, что Active Record - это слишком часто используемый шаблон, который поощряет смешивание бизнес-логики с кодом персистентности. Он не очень хорошо скрывает реализацию хранилища от уровня модели и связывает модели с базой данных. Существует множество альтернатив (описанных в PoEAA), таких как Table Data Gateway, Row Data Gateway и Data Mapper, которые часто предоставляют лучшее решение и, безусловно, помогают обеспечить лучшую абстракцию хранилища. Кроме того, ваша модель не должна храниться в базе данных; как насчет хранения их в виде XML или доступа к ним через веб-сервисы? Насколько легко было бы изменить механизм хранения ваших моделей?

Тем не менее, Active Record не всегда плох и идеально подходит для простых приложений, где другие варианты будут излишними.

Answer 7

Это очень просто ...избегайте Шаблонов проектирования, которые непонятно вам или тем, кто вы не чувствуете себя комфортно в.

Назову некоторые из них ...

есть некоторые непрактичные паттерны, как , например ,:

• Interpreter
• Flyweight

есть также некоторые труднее уловить, как , например ,:

• Abstract Factory - Полный абстрактный фабричный шаблон с семействами созданных объектов - это не такой легкий процесс, как кажется
• Bridge - Может получиться слишком абстрактным, если абстракция и реализация разделены на поддеревья, но в некоторых случаях это очень полезный шаблон
• Visitor - Понимание механизма двойной отправки действительно НЕОБХОДИМО

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

• Singleton - на самом деле не совсем плохой шаблон, просто СЛИШКОМ часто используется (часто там, где он не подходит)
• Observer - отличный рисунок ...это просто значительно усложняет чтение и отладку кода
• Prototype - компилятор сделок проверяет динамичность (которая может быть хорошей или плохой ...зависит от обстоятельств)
• Chain of responsibility - слишком часто просто принудительно / искусственно внедряется в дизайн

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

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

Итак, что же будет дальше...

• Шаблоны проектирования в первую очередь это ОБЯЗАТЕЛЬНОЕ УСЛОВИЕ
• Создание исходных текстов это "первая помощь"

Answer 8

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

Answer 9

Некоторые говорят, что локатор служб является антишаблоном.

Answer 10

Я полагаю, что шаблону наблюдателя есть за что ответить, он работает в очень общих случаях, но по мере усложнения систем он становится кошмаром, требующим уведомлений OnBefore (), OnAfter () и частой публикации асинхронных задач в избежать повторного входа. Гораздо лучшим решением является разработка системы автоматического анализа зависимостей, которая обрабатывает все обращения к объектам (с барьерами чтения) во время вычислений и автоматически создает ребро в графе зависимостей.

Answer 11

Дополнение к сообщению Спойка, Рефакторинг к шаблонам - это хорошее чтение .

Answer 12

Итератор - это еще один шаблон GoF, который следует избегать или, по крайней мере, использовать его, только когда ни одна из альтернатив не доступна.

Альтернативы:

<Ол>

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

селекторы & # 224; La LINQ или JQuery. Они должны использоваться, когда for-each не подходит, потому что не все объекты из контейнера должны быть обработаны. В отличие от итераторов, селекторы позволяют в одном месте указывать, какие объекты нужно обрабатывать.