Для каждого проекта программирования менеджеры с прошлым опытом программирования стараются проявить себя, когда они рекомендуют некоторые шаблоны проектирования для вашего проекта. Мне нравятся шаблоны проектирования, когда они имеют смысл или если вам нужно масштабируемое решение. Например, я положительно использовал шаблоны «Прокси», «Наблюдатели» и «Команды» и делаю это каждый день. Но я действительно сомневаюсь в том, чтобы использовать шаблон фабрики, если есть только один способ создания объекта, поскольку фабрика может упростить все в будущем, но усложнит код и приведет к дополнительным накладным расходам.
Итак, мой вопрос касается моей будущей карьеры и моего ответа на типы менеджеров, выбрасывающих случайные имена шаблонов:
Какие шаблоны дизайна вы использовали, что отбросило вас назад в целом? Какие наихудшие шаблоны проектирования следует рассмотреть, за исключением одной ситуации, в которой они имеют смысл (читай: какие шаблоны проектирования определены очень узко)? (Как будто я искал негативные отзывы об общем хорошем продукте Amazon, чтобы понять, что больше всего мешает людям при использовании шаблонов дизайна.) И здесь я говорю не об анти-шаблонах, а о шаблонах, которые обычно рассматриваются как «хорошие» шаблоны.
Изменить: как некоторые ответили, проблема чаще всего в том, что шаблоны не "плохие", но "используются неправильно". Если вы знаете шаблоны, которые часто неправильно используются или даже сложны в использовании, они также подойдут как ответ.
Ответы:
Я не верю в плохие паттерны, я верю, что паттерны могут быть плохо применены!
Для этого ответа я рассмотрел только шаблоны 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.
источник