К сожалению, не успел к началу вопроса, многое уже посоветовали, но эту статейку вроде не успели еще кинуть. Недавно нашел ее и просто поразился как просто и доступно это изложено + с примерами кода на php. Просто шикарный перевод великолепной статьи!

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

Так что посоветую 2 варианта изучения.
1) Тупо работаешь над сложные проектами, только действительно сложными, а не сайтиками на cms. И со временем ты начинаешь встречаться с проблемами. Тогда открываешь паттерны и тебе не придется даже как то их особо понимать, потому что это будет естевственно для тебя. Я думаю ты используешь ide вместо редактора кода. Но к примеру я помню тот момент, когда я пользовался саблаймом и знал, что есть ide, но я писал на тот момент простые вещи и когда мне говорили, почему я не юзаю ide, ведь в ней столько всего, я не понимал их потому что мне и саблайма за глаза хватало. Но пришло время, когда надо было то и се и саблайма стало мало. И тут открываю ide, а там уже есть все необходимое и думаешь в такие моменты, как я раньше этим не пользовался. А дело в том, что раньше и не надо было. Может неудачный пример, но вы поняли) Конечно, этот вариант изучения не совсем реален, по скольку сложный проект еще найти надо, да еще попасть в команду, которая не говнокодит, так как и крупные проекты бывают достаточно плохо написаны. Но можно как вариант к примеру делать свою cms и применять в ней как можно больше паттернов.

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

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

Шаблон проектирования или паттерн (англ. design pattern ) в разработке программного обеспечения - повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

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

Классификация паттернов

В настоящее время наиболее популярными паттернами являются паттерны проектирования. Одной из распространенных классификаций таких паттернов является классификация по степени детализации и уровню абстракции рассматриваемых систем. Паттерны проектирования программных систем делятся на следующие категории:

Архитектурные паттерны

Паттерны проектирования

Архитектурные паттерны , являясь наиболее высокоуровневыми паттернами, описывают структурную схему программной системы в целом. В данной схеме указываются отдельные функциональные составляющие системы, называемые подсистемами, а также взаимоотношения между ними. Примером архитектурного паттерна является хорошо известная программная парадигма "модель-представление-контроллер" (model-view-controller - MVC).

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

Идиомы , являясь низкоуровневыми паттернами, имеют дело с вопросами реализации какой-либо проблемы с учетом особенностей данного языка программирования. При этом часто одни и те же идиомы для разных языков программирования выглядят по-разному или не имеют смысла вовсе. Например, в C++ для устранения возможных утечек памяти могут использоваться интеллектуальные указатели. Интеллектуальный указатель содержит указатель на участок динамически выделенной памяти, который будет автоматически освобожден при выходе из зоны видимости. В среде Java такой проблемы просто не существует, так как там используется автоматическая сборка мусора. Обычно, для использования идиом нужно глубоко знать особенности применяемого языка программирования.

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

Описание паттернов

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

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

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

Решение. Здесь указывается, как именно данное решение связано с проблемой, приводится пути ее решения.

Результаты использования паттерна. Обычно приводятся достоинства, недостатки и компромиссы.

Результаты применения паттернов

Они (паттерны) позволяют суммировать опыт экспертов и сделать его доступным рядовым разработчикам.

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

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

Паттерны упрощают реструктуризацию системы независимо от того, использовались ли паттерны при ее проектировании.

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

http://citforum.ru/SE/project/pattern/#3

Типы шаблонов проектирования

Основные

Шаблон делегирования

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

Абстрактная фабрика, Прототип, Строитель

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

Адаптер, Мост, Приспособленец, Заместитель

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

Стратегия, Состояние

Concurrency - Параллелизм

Частные

Шаблоны параллельного программирования (Concurrency)

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

Привести в пример паттерн проектирования – один из самых популярных запросов на собеседованиях. Объясняем порождающие паттерны простыми словами.

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

Вы хотите создать автомобиль, но поняитя не имеете, с чего начать. Сколько должно быть у него колес? 3, 4, 5? Вы не знаете точно, потому что никогда до этого не занимались проектированием автомобилей. К счастью, до вас люди занимались этим десятилетиями и вы точно знаете, что для конкретно вашего варианта автомобиля потребуется база из 4 колес. Вам не нужно экспериментировать и строить трицикл, чтобы убедиться в его неэффективности.

Паттерны не привязаны к конкретному языку программирования, это просто подход к проектированию.

Порождающие паттерны

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

Singleton (одиночка)

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

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

Но главное в одиночке то, что создав станцию один раз, ей может пользоваться сколько угодно людей. Смысл в том, что когда вы скажете «Мне нужна телефонная станция», вам ответят не «Нужно построить новую», а «Она находится там-то».

Registry (реестр, журнал записей)

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

Еще один пример одиночки-реестра – бухгалтерия. Фирма не создает бухгалтерию каждый раз, когда она ей понадобится. В то же время, в бухгалтерии хранятся записи обо всех сотрудниках фирмы, как в реестре.

Multiton (пул «одиночек»)

По сути данный паттерн – это реестр одиночек, каждый из которых имеет имя, по которому к нему можно получить доступ.

Object pool (пул объектов)

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

Factory (фабрика)

Фабрика – достаточно точное название для этого паттерна. Когда вам понадобится пакет сока, вы обращаетесь к фабрике с соответствующим запросом, она в свою очередь копирует эталон и передает вам его экземпляр. Что при этом происходит внутри фабрики и как она это делает вас не беспокоит.

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

Builder (строитель)

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

Prototype (прототип)

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

В данном случае, пакет является прототипом и создает на своей основе другие объекты, с требуемыми вам параметрами.

Factory method (фабричный метод)

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

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

Для этого мы создаем основной отдел по производству пакетов-основ и предупреждаем все подотделы, что они должны производить нужный пакет с соком про простому «Надо» (т.е. каждый подотдел должен реализовать паттерн «фабричный метод»). Поэтому каждый подотдел заведует только своим типом сока и реагирует на слово «Надо».

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

Lazy initialization (отложенная инициализация)

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

Dependency injection (внедрение зависимости)

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

«Внедрение зависимости» позволяет перекладывать и взаимозаменять отдельные части программы без потери общей функциональности.

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

По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The "Gang of Four") в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

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

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

К изучению паттернов я дам такие советы:

1) Прочтите пару книжек, чтобы понять, что это за зверь и с чем его едят. Можно взять одну из вариаций книжки GoF или какие-то производные для вашего стека разработки - познакомиться с основными популярными шаблонами. Сразу после этого я посоветовал бы прочесть книжку "Горький вкус Java" (Брюс Тейт) - она про анти-паттерны. Это чтобы понять обратную сторону их использования. Мне понравилась и уберегла думаю от многих проблем. То что на примере Java - неважно. Речь идет о шаблонах, так что представителям других стеков (к которым отношусь и я) будет просто понять все равно.

2) Постарайтесь осознать, доводилось ли вам сталкиваться в работе раньше с чем-то, что является или могло бы легко стать одним из шаблонов. Где получалось применить концепт верно, а где из-за этого только проблемы были.

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

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

Я даже пожалуй посоветовал бы подойти к освоению айтишной архитектурной мудрости с другой стороны - со стороны нефункциональных требований или так называемых "-ilities" - их много. вот описаны 7 штук. А вообще их десятки .

Среди прочих - такие как maintainability (простая поддержка кода), scalability (масштабируемость), extensibility (расширяемость), availability (устойчивость) и тп. Если, проектируя свое приложение, вы задумываетесь об этих "илитях" и стараетесь их обеспечить в необходимом проекту объеме, то, как правило, ваше приложение будет иметь отличную архитектуру. При этом шаблоны проектирования в ней появятся лаконично сами собой.

Поскольку идея использовать шаблоны - это попытка опытных программных инженеров дать десяток готовых рецептов менее опытным, чтобы пока они не научились варить "вкусную кашу", они не варили уж что-то совсем несъедобное. :) Учитесь "готовить", разбирайтесь в -ilites:) и все будет хорошо

Современное программирование практически невозможно без применения специальных шаблонов проектирования (паттернов). Паттерны представляют собой специальные способы построения и организации программного продукта, которое позволяет решить наиболее «популярные» сложности и ошибки в программировании. Обобщая данный термин, можно сказать, что паттерны представляют собой своеобразный свод правил, который позволяет избавить программиста от общих, формализованных проблем.
Все известные на сегодняшний день паттерны проектирования можно разделить на несколько подвидов, это: порождающие шаблоны, паттерны поведения, структурные и, так называемые, принципы SOLID.
К порождающим паттернам относятся следующие: Абстрактная фабрика, Builder, Factory Method, Singleton, Prototype. Они называются порождающими в связи с тем, что подобные паттерны абстрагируют процесс создания экземпляров классов и объектов.
К поведенческим паттернам относятся: Interpreter, Iterator, Mediator, Template Method, State, Strategy, Visitor. Они называются поведенческими потому что определяют процессы взаимодействия между классами и объектами, соответственно, определяют поведение.
Структурные паттерны включают в себя: Proxy, Facade, Composite, Bridge, Adapter. Такие паттерны в разработке программного обеспечения, в коммерческих целях, встречаются довольно редко, поэтому и их описание найти немного проблематично. По сравнению с перечисленными выше паттернами, эти используются не часто, только в определенных, исключительных случаях. Подобные шаблоны рассматривают классы и объекты, используемые в программе, как структуры, соответственно, более сложные.
Применение подобных паттернов позволяет улучшить понимание кода, например, если вы работаете не один, а в команде, а также упростить процедуру внедрения новых участков кода или изменения старых, без необходимости в написании избыточного кода.
Принципы Solid, по своей сути представляют один большой шаблон проектирования, который включает в себя несколько маленьких паттернов. SOLID, как можно догадаться, является акронимом и означает следующее: S – принцип единственной обязанности, O - открытости и закрытости, L - подстановки Лисков, I - разделения интерфейсов в программу, и D -инверсии зависимостей. В отличии от представленных выше паттернов, подобные принципы нельзя назвать какими-то шаблонами решения формализованных проблем. Эти принципы позволяют создать грамотное, структурированное программное решение, которое упрощает изменение определенных участков кода и даже его изменение.
Таким образом, подытоживая все описанное выше, можно сказать, что программирование без применения принципов SOLID или паттернов, буквально невозможно. Скорее всего, работать без них можно только если вы создаете какое-то небольшое приложения, над которым в дальнейшем будете также работать только вы один и точно знаете – какой участок кода за что отвечает. Если вы работаете в команде, то без применения шаблонов и принципов – вам далеко не уйти. Так будет проще разбираться в коде вашим товарищам и сама работа станет легче.