Так что странно задавать два вопроса подряд, но они не очень связаны, и я не хочу их объединять, но я не спамлю вопросы, обещаю!

Во всяком случае, я недавно закончил колледж, и мое образование касалось только шаблонов проектирования ... мы реализовали несколько простых, затронули тот факт, что были более сложные, и получили указание обратиться к книге GoF, если мы хотел узнать больше. У меня вопрос, стоит ли изучать шаблоны в книге GoF? Мне всегда казалось нелогичным пытаться сделать задачу подходящей для классического шаблона, но, очевидно, книга и шаблоны известны по определенной причине. Достаточно ли они появляются, чтобы я их изучал?

Еще раз спасибо!

Как обычно

По-разному

Это зависит от того, сколько ООП вы сделали, узнаете ли вы или сможете ли вы использовать шаблоны проектирования

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

С другой стороны ... пять пальцев!

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

Это помогает узнать шаблоны, чтобы вы знали, когда их использовать, а когда нет.

Да, вы должны изучить их.

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

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

Есть еще одна причина, по которой стоит читать: она научит вас думать . Конечно, это не серебряная пуля, но все же бесценное вдохновение.

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

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

Книга GOF является отличным источником многих полезных инструментов, которые мы используем ежедневно .

Самым важным преимуществом знания немного о Design Patters является то, что вы знаете, что означают эти термины. Другими словами, вы знаете общий словарный запас .

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

Примерами являются Visitor, Singleton и Decorators.

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

ДА но с осторожностью!

ДА часть:

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

Картинка с осторожной частью:

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

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

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

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

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

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

ДА, короче говоря, шаблоны обучения не только того стоят ... вы ограничиваете себя, НЕ изучая их. Я не хочу описывать все мотивирующие принципы и общую форму решения, когда я говорю: «Выглядит как посетитель для меня».

Вот их сайт: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

Шаблоны проектирования, описанные GoF, являются своего рода естественным продолжением парадигмы ОО. Если вы не совсем понимаете цели ООП (инкапсуляция, разделение задач, принцип СУХОЙ, модульность и т. Д.), То попытка успешного применения шаблонов проектирования не имеет большого смысла.

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

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

Шаблоны проектирования пытаются решить проблемы дизайна.

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

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

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

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

У меня вопрос, стоит ли изучать шаблоны в книге GoF?

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

Достаточно ли они появляются, чтобы я их изучал?

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

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

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