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

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

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

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

На мой взгляд, вопрос: " используете ли вы Дизайн-Шаблон?", сам по себе немного ущербен, потому что ответ универсален YES.

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

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

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

Однако анти-паттерн относится к совершенно другому классу. Вы действительно хотите активно избегать анти-паттернов. Вот почему название anti-pattern так противоречиво.

Чтобы вернуться к вашему первоначальному вопросу:
"Использую ли я шаблоны дизайна?- Ну да!
"Действительно ли я активно склоняюсь к моделям дизайна?", Нет.

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

Кроме того, вот некоторые другие шаблоны, которые могут быть полезны:

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

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

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

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

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

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

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

Есть много шаблонов проектирования помимо простых, которые используются в "real world". Хороший пример сайте StackOverflow использует модель-представление-контроллер. Я несколько раз использовал фабрики класса в проектах для моего работодателя, и я видел много уже написанных проектов, использующих их.

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

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

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

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

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

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

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

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

Да, я использую много хорошо известных шаблонов проектирования, но я также в конечном итоге создаю некоторое программное обеспечение, которое, как я позже узнаю, использует шаблон дизайна 'named'. Самые элегантные, многоразовые конструкции можно было бы назвать 'pattern'. Это очень похоже на танцевальные движения. Мы все знаем вальс и 2-шаг, но не у всех есть название для "удара и бега", хотя большинство из нас делают это.

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

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

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

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

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

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

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

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

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

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

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

Да.

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

До сих пор я видел адаптер, посетитель, фасад, модуль, наблюдатель и что-то очень близкое к композиту и итератору. Из-за природы языков это в основном strutural шаблоны, которые используются. Кроме того, я не всегда уверен, что люди, которые их используют, делают это сознательно :D

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

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

Шаблоны дизайна определенно играют большую роль во всех моих идеях "for the future".