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

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

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

Вы пробовали книгу «Банда четырех»?

Паттерны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования

Я прочитал три книги и все еще не очень хорошо разбирался в шаблонах, пока не прочитал Шаблоны проектирования Head First от OReilly. Эта книга открыла мне глаза и действительно хорошо объяснила.

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

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

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

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

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

Удачи

Не знаю, какая книга лучшая, но пуристы могут сказать Паттерны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования

Что касается моего личного фаворита, мне нравится Шаблоны проектирования Head First, опубликованный O'Reilly. Он написан разговорным голосом, который мне нравится. Когда я его читал, я одновременно просматривал свой исходный код, чтобы увидеть, применимо ли оно к тому, что я читал. Если это так, я провел рефакторинг. Так я узнал о цепочке ответственности.

Практика - Практика - Практика.

Практика, практика, практика.

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

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

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

Это действительно то же самое, что и кодирование; K&R может быть «библией» для C, но чтение ее от корки до корки несколько раз не дает ни одного практического опыта; нет замены опыту.

Было дано много хороших примеров. Я бы хотел добавить одно:

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

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

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

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

Я возглавлял несколько дискуссионных групп по шаблонам проектирования (наш сайт) и прочитал 5 или 6 книг по шаблонам. Я рекомендую начать с книги Head First Design Patterns и посетить или начать дискуссионную группу. Книга Head First на первый взгляд может показаться немного Хасборо, но большинству людей она нравится после прочтения одной или двух глав.

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

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

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

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

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

Идея чтения шаблонов проектирования, практика их кодирования на самом деле не поможет ИМО. Когда вы читаете эти книги: 1. Ищите основную проблему, которую решает конкретный шаблон проектирования. Лучше всего начать с Creational Patterns. 2. Я уверен, что вы писали код в прошлом, проанализируйте, сталкивались ли вы с теми же проблемами, решение которых нацелены на решение шаблонов проектирования. 3. Попытайтесь переделать код или, возможно, начать заново.

О ресурсах вы можете проверить эти

1. www.dofactory.com
2. Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения (серия профессиональных вычислений Addison-Wesley) Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона М. Влиссидеса
3. Паттерны архитектуры корпоративных приложений Мартина Фаулера

1 - быстрое начало, 2 - углубленное изучение .. 3 объяснят или должны заставить вас задуматься, что вы узнали в 2, подходит для корпоративного программного обеспечения.

Мои 2 цента ...

Я думаю, что также сложно изучать шаблоны проектирования. Вы должны знать больше об ООП и иметь некоторый опыт разработки средних и крупных приложений. Что касается меня, я учусь как группа разработчиков, чтобы проводить обсуждения. Следим за Учебное руководство по шаблонам проектирования, что они завершили изучение паттернов. Разработчики C# и JavaScript объединились. Мне кажется необычным то, что разработчик C# пишет коды на JavaScript, а разработчик JavaScript делает то же самое для кодов C#. После того, как я ухожу с собрания, я также ищу и читаю дома несколько книг для рецензирования. На мой взгляд, лучший способ понять и запомнить больше - вести блог с примерами как на C#, так и на JavaScript, здесь http://tech.wowkhmer.com/category/Design-Patterns.aspx.

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

Например:

Заводской метод:

Прочтите мир: я просто даю деньги 5, 10 или 20 долларов, и он будет производить пиццу обратно, ничего не зная о том, как это делается. Я просто получаю маленькую, среднюю или большую пиццу в зависимости от вложенных денег, так что я могу есть или делать что угодно.

Программирование: клиент просто передает значение параметра $ 5, $ 10 или $ 20 в фабричный метод, и он возвращает объект Pizza обратно. Таким образом, клиент может использовать этот объект, не зная, как он обрабатывается.

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

Вы читали «Объяснение шаблонов дизайна» Аллана Шеллоуэя.

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

Проблемы можно разделить на две части: общие и разные. Как только это будет сделано, мы сопоставляем общие вещи с интерфейсом, а то, что зависит от реализации. По сути, в этот «образец» попадают многие паттерны.

Например, в шаблоне стратегии общие вещи выражаются как контекст стратегии, а переменные части выражаются как конкретные стратегии.

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

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

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

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

Книга поможет вам понять основные концепции, если только вы не реализовали их в реальном мире, вы НЕ МОЖЕТЕ БЫТЬ МАСТЕРОМ ДИЗАЙН-УЗОРОВ.

Задайте себе следующие вопросы:

Что они делают?

Что они разделяют / соединяют?

Когда их использовать?

Когда не стоит их использовать?

Какая недостающая языковая функция заставит их исчезнуть?

Какой технический долг вы получаете, используя его?

Есть ли более простой способ выполнить работу?

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

Мои два цента за такой старый вопрос

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

1. Изучите разработку через тестирование (TDD)
2. Изучите рефакторинг
3. Изучите шаблоны

Большинство людей игнорируют 1, многие считают, что могут сделать 2, и почти все сразу выбирают 3.

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

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

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

Дерек Банас сделал на YouTube уроки по созданию шаблонов, которые мне очень нравятся:

http://www.youtube.com/playlist?list=PLF206E906175C7E07

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