Я слышал и читал о случаях, когда люди сталкивались с случаями чрезмерного использования шаблонов дизайна. Хорошо, пропущенные шаблоны проектирования понятны. Что на самом деле означает чрезмерные шаблоны проектирования?
Есть ли у вас примеры и почему вы считаете, что существует слишком много шаблонов?
singleton, вероятно, является наиболее чрезмерным шаблоном проектирования. Я часто вижу, что он используется во многих случаях, когда он выходит из сферы действия и гораздо более подходит для непосредственного создания объектов.
После этого я считаю, что factory pattern можно использовать как ярлык для создания объектов, много раз без реальной необходимости.
Ориентация объекта, которая больше не является шаблоном проектирования, а образует образ жизни. Я видел много процедурного кода, искаженного объектами и множеством объектов ради объектов, потому что zeitgeist говорит "предположительно, что вы объектно-ориентированный", когда несколько строк C и структуры будут делать то же самое.
Я цитирую его как самый сложный шаблон дизайна, потому что он (вероятно) наиболее широко используемый шаблон дизайна, и его заслуги редко подвергаются сомнению.
Я проголосую за ActiveRecord.
Многие популярные структуры доступа к данным используют ActiveRecord в качестве единственного шаблона доступа к данным, своего рода одноразовое решение, даже несмотря на то, что книга Мартина Фаулера "Шаблоны архитектуры корпоративных приложений" описывает несколько других шаблонов доступа к данным и детали сильные стороны каждого шаблона и как решить, когда использовать каждый шаблон.
Я думаю, Синглтон становится легко злоупотребляемым (хотя он, безусловно, использует его легитимность).
Зависимость от шаблона Singleton называется Singletonitis.:) Симптомы включают, по крайней мере, излишне высокую сцепность, а тестирование становится все труднее.
Изменить. Как предписанное лечение для Singletonitis, вы можете попробовать Inline Singleton, описанный в Рефакторинг для шаблонов Джошуа Кериевского.
Изменить 2. Для хорошего обсуждения синглтонов см. этот более старый вопрос: Что плохого в синглтонах
(иногда) так называемые JavaBeans-Pattern: getters и seters для каждого поля. Очень сомнительный и чрезвычайно распространенный.
ПРЕАМБУЛА:. В целом, Singleton считается самым злоупотребляемым шаблоном, если не что иное, как тот факт, что многие будут использовать его для написания встроенного программирования на самом деле, если не в действительности, тогда как другие используйте его в качестве замены для глобальных переменных.
ТЕЛО: Существует книга, называемая "Язык шаблонов", которая предшествует знаменитому GoF на несколько лет. Он требует аналогичного языка среди различных аспектов проекта - это, по-видимому, оказало большое влияние на "шаблоны проектирования", а те, кто знает, что оба текста считают его превосходным.
Мой личный опыт заключается в том, что GoF полезен только при определенных обстоятельствах и далеко не охватывает весь ООП. На самом деле я нахожу довольно забавным, что некоторые из шаблонов устарели на других языках, а другие просто избыточно описывают один и тот же сценарий (действительно ли существует большая разница между тем, что адаптируется и переводится?)
Образцы, в общем, хорошо. Хорошо, что Singletons обычно используют статический метод getInstance. Хорошо, что многие структуры MVC используют аналогичные соглашения об именах. С другой стороны, шаблоны - это не все, и это нужно помнить.
Рекомендуемое чтение: http://perl.plover.com/yak/design/
Синтаксический шаблон, который подходит только в очень немногих случаях и делает тестирование сложнее. Он не только слишком часто используется, но часто плохо реализуется в Java и С# - люди часто спешат в блокировку с двойным проверкой, когда это не только неуместно, но и относительно сложно получить право.
EDIT: Я действительно должен был понять, что все будут публиковать одно и то же.
Следующий пример, шаблон factory и, в частности, его использование в API DOM Java. Blech.
Я бы сказал, что Singleton хорошо используется. Часто есть гораздо лучшие решения, чем использование, по существу, глобальной переменной.
Я собираюсь взвесить на сильно злоупотребляемом Синглтоне. Довольно часто разработчики учатся только одному шаблону и используют его, когда статический класс будет таким же эффективным.
Я думаю, что худшая проблема, чем злоупотребление шаблонами дизайна, - это шаблоны, неправильно используемые энтузиастами-разработчиками, которые недавно изучили новый инструмент шаблонов и решили, что им нужно попробовать. Недавно я читал некоторые из блога Misko Hevery (http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/) записи об инъекции зависимостей. Одно из его основных утверждений состоит в том, что одноэлементный шаблон, реализованный как глобальный экземпляр, сильно ограничивает тестируемость и его следует избегать.
Несколько дней назад я прочитал интересное мнение о шаблонах из блога Кристиана Грубера. Он предлагает, чтобы они были полезны в качестве инструмента для обсуждения архитектуры, но не должны использоваться во время дизайнерской концепции, чтобы архитектура программного обеспечения не ухудшалась в том, что он называет "краской по номерам". См. Параграф "Шаблоны проектирования": http://www.geekinasuit.com/2008/12/testability-re-discovering-what-we.html.
Таким образом, возможно, проблема с шаблонами проектирования - неправильное применение и туннельное видение, вызванное восприятием того, что все хорошо разработанное программное обеспечение должно вписываться в один из шаблонов, описанных в Gang of Four.
Это было фактически обсуждено нашим одним и только Джеффом Этвудом в Coding Horror:
Я продолжаю видеть шаблон провайдера, используемый там, где есть только один поставщик. Это похоже на ужасную массу дополнительной работы без каких-либо преимуществ.
Я тоже проголосую за Singleton: глобальная в абстрактной одежде.
И Factory, так как это облегчает не думать о том, как объекты соединены вместе в данной программе.