Вы используете шаблоны проектирования?

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

Действительно ли они приносят пользу вашей работе? Или это просто то, о чем люди говорят, чтобы звучать умно?

Примечание. В этом вопросе игнорируйте «простые» шаблоны проектирования, такие как Singleton . Я говорю о разработке вашего кода, чтобы вы могли воспользоваться преимуществами Model View Controller и т. Д.

Ответов (15)

Решение

Любая большая программа, которая хорошо написана, будет использовать шаблоны проектирования, даже если они не названы и не распознаются как таковые. Вот что такое шаблоны проектирования, повторяющиеся и естественные конструкции . Если вы взаимодействуете с уродливым API, вы, вероятно, обнаружите, что реализуете его, Facade чтобы очистить его. Если у вас есть обмен сообщениями между компонентами, которые вам нужно разделить, вы можете использовать Observer . Если у вас есть несколько взаимозаменяемых алгоритмов, вы можете в конечном итоге использовать Strategy .

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

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

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

да. Шаблоны проектирования могут быть замечательными при правильном использовании. Как вы упомянули, теперь я использую Model-View-Controller (MVC) для всех своих веб-проектов. Это очень распространенный шаблон в веб-пространстве, который делает код на стороне сервера намного чище и хорошо организованным.

Помимо этого, вот еще несколько шаблонов, которые могут быть полезны:

  • MVVM (Model-View-ViewModel): шаблон, аналогичный MVC; используется для приложений WPF и Silverlight.

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

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

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

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

да.

Мы даже используем их в моей текущей работе: кодирование мэйнфреймов с помощью COBOL и PL / I.

До сих пор я видел Adapter, Visitor, Facade, Module, Observer и что-то очень близкое к Composite и Iterator. Из-за природы языков используются в основном структурные шаблоны. Кроме того, я не всегда уверен, что люди, которые их используют, поступают так осознанно: D

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

Да, Factory, Chain of Responsibility, Command, Proxy, Visitor и Observer, среди прочего, используются в кодовой базе, с которой я работаю ежедневно. Что касается MVC, этот сайт, кажется, использует его достаточно хорошо, и разработчики не смогли сказать достаточно хороших слов в последнем подкасте .

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

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

Имейте в виду, мы не часто их используем.

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

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

Мосты используются при попытке склеить две разные технологии (например, Cocoa и Ruby на Mac)

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

Просто нужно быть осторожным, чтобы не стать и космонавтом-архитектором !

На мой взгляд, сам по себе вопрос: « Используете ли вы шаблон проектирования?» - это немного ошибочно, потому что универсальный ответ - ДА.

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

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

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

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

Возвращаясь к исходному вопросу:
«Использую ли я шаблоны проектирования?», Да!
«Я активно склоняюсь к шаблонам проектирования?», Нет.

MVC очень хорошо известен, поэтому да, мы довольно часто используем шаблоны проектирования. Теперь, если вы спрашиваете о шаблонах «Банда четырех», я использую несколько, потому что другие сопровождающие знают дизайн и то, над чем мы работаем в коде. Однако есть несколько, которые остаются довольно неясными в отношении того, что мы делаем, поэтому, если я использую один, я не получу всех преимуществ от использования шаблона.

Насколько они важны? Да, потому что это дает вам возможность быстро и эффективно и общепринятым образом говорить о разработке программного обеспечения. Можете ли вы сделать более индивидуальные решения, ну да (вроде как)?

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

Да, я использую много хорошо известных шаблонов проектирования, но в конечном итоге я создаю программное обеспечение, которое, как я позже узнаю, использует «именованный» шаблон проектирования. Самые элегантные, многоразовые дизайны можно назвать «паттернами». Это очень похоже на танцевальные движения. Все мы знаем вальс и двухступенчатый, но не у всех есть название для «bump and scoot», хотя большинство из нас это делает.

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

Мне также очень нравятся « Шаблоны архитектуры корпоративных приложений» Мартина Фаулера . Когда возникает проблема или задача, я перехожу к соответствующему разделу (в основном это справочник) и читаю несколько обзоров шаблонов. Как только я получу лучшее представление об общей проблеме и существующих решениях, я начинаю видеть долгосрочный путь, по которому мой код, вероятно, пойдет на основе опыта других. В конечном итоге я принимаю гораздо лучшие решения.

Шаблоны дизайна определенно играют большую роль во всех моих идеях «на будущее».

Помимо простых, существует множество шаблонов проектирования, которые используются в «реальном мире». Хороший пример Stackoverflow использует шаблон контроллера представления модели. Я несколько раз использовал Class Factories в проектах для моего работодателя, и я видел много уже написанных проектов, использующих их.

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

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

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

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

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

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

Как вы знаете, антипаттерн - тоже опасная вещь, и это случается, когда у вас мало знаний о шаблонах проектирования. А рефакторинг антипаттернов намного сложнее. В качестве рекомендуемой книги по этой проблеме, пожалуйста, прочтите "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis".