Какие шаблоны дизайна являются наихудшими или наиболее узкими? [закрыто]

Для каждого проекта программирования менеджеры с прошлым опытом программирования стараются проявить себя, когда они рекомендуют некоторые шаблоны проектирования для вашего проекта. Мне нравятся шаблоны проектирования, когда они имеют смысл или если вам нужно масштабируемое решение. Например, я положительно использовал шаблоны «Прокси», «Наблюдатели» и «Команды» и делаю это каждый день. Но я действительно сомневаюсь в том, чтобы использовать шаблон фабрики, если есть только один способ создания объекта, поскольку фабрика может упростить все в будущем, но усложнит код и приведет к дополнительным накладным расходам.

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

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

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

Я не верю в плохие паттерны, я верю, что паттерны могут быть плохо применены!

• ИМХО, синглтон является наиболее злоупотребляемым и наиболее неправильно применяемым паттерном. Люди, кажется, заболевают синглтоном и начинают видеть возможности для синглетонов повсюду, не рассматривая альтернативы.
• ИМХО шаблон посетителя имеет самое узкое применение и почти никогда не будет оправдывать добавленную сложность. Хороший PDF можно получить здесь . Действительно, только когда у вас есть структура данных, которую, как вы знаете, будет проходить при выполнении различных операций над структурой данных, не зная заранее всех способов, дайте паттерну посетителя шанс для борьбы. Это красиво, хотя :)

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

Кроме Синглтона и Посетителя, уже упомянутых другими авторами, я не знаю «пресловутых» шаблонов дизайна. ИМХО, самые большие проблемы не в том, что конкретный шаблон дизайна является «неправильным», а в том, что разработчики слишком охотно применяют шаблоны.

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

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

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

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

Singleton. Это один из паттернов GOF, который сейчас чаще называют анти-паттерном. Одна из причин этого заключается в том, что Singleton делает код более сложным для тестирования.

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

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

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

Доктор WPF сделал ироничный пост об этом в своей статье MV-poo .

Некоторые шаблоны в книге GOF специфичны для C ++, в том смысле, что они менее применимы в языках с отражением, например, шаблон Prototype менее важен в Java.

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

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

Завод. Я видел код, реализующий его, который создает только один тип. Это совершенно бесполезный код ИМО. Не помогает то, что многие примеры в Интернете полностью придуманы. Пиццерия?

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

одиночка

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

Потокобезопасность - одна проблема с синглетонами. Обработка исключений - это еще одно - если синглтон не может быть создан должным образом - вы не всегда знаете, можете ли вы безопасно отловить ошибку, особенно если это был один из тех объектов, которые были созданы «до main». И затем есть проблема очистки после этого.

Я предпочитаю использовать один синглтон, и все остальные "подражатели" "подписываются" на ваш. Мое наиболее распространенное использование синглтонов - это обработка «события рупора»: вы просто «вещаете миру», что событие произошло, и любой, кто слушает, будет обрабатывать событие. Таким образом, вы отделяете события, которые на самом деле происходят, с тем, что их слушает. (Регистрация, сигналы и т. Д.)

посетитель

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

Можно, хотя и грязно, разрешить расширение в обоих направлениях, но это не полностью использует шаблон посетителя в его обычной форме. Самым распространенным приложением для этого является печать объектов: у вас есть разные способы печати объектов и различных объектов, которые необходимо распечатать. Вы должны быть в состоянии расширить это в обоих направлениях. (Печать означает любой вид превращения объектов в поток: сохранение в файле / запись в консоль / графический интерфейс пользователя и т. Д.).

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

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

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

Нет плохих шаблонов, только плохие люди.

Я бы предпочел унаследовать легко читаемый код, который делает что-то ясное, но немного многословно или нет (повторяю злобную музыку), может быть повторно использован (задыхается!), Чем какая-то миш-мес InheritAbstractTemplateFaucetSink<Kitchen>.

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

Для дальнейшего чтения взломайте, откройте часть кода на C в разумных реализациях заголовков posix или clibs и играйте в паттерн. Этот код был написан одними из самых умных и самых преданных программистов в мире. Вы знаете, сколько абстрактных фабричных шаблонов вы увидите? ... НИКТО!. Еще больше шансов, что если вы поймете другие части происходящего, вы найдете логику очень простой для понимания и отслеживания.

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

После этого я оставлю вам, вероятно, лучшую (соответствующую) цитату в области компьютерных наук.

« Существует два способа конструирования программного обеспечения: один из них состоит в том, чтобы сделать его настолько простым, чтобы в нем явно не было недостатков, а другой способ - сделать его настолько сложным, чтобы не было явных недостатков. Первый способ гораздо сложнее . "

• Тони Хоар (изобретатель быстрой сортировки, отец современного дизайна ОС, создатель логики Хоара и лауреат премии Тьюринга)

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