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

izekia, если точнее, это сказал Грег Ирвин, и звучало оно так:





А вообще, я сейчас стараюсь совмещать небольшое проектирование на основе модели предметной области, TDD и рефакторинг -- очень нравится, гораздо эффективнее всё получается.

Это классика. К прочтению обязательна.

А еще, если к этому прикрутить Design Patterns вообще вещь получается.
Рекомендую по этому поводу книженцию Джошуа Кириевски "Рефакторинг с использованием шаблонов".

UML Применяю всегда. Design Patterns всегда. А если мой работодатель хочет Fast & Dirty то пусть ищет другого программиста.

ООП из книге "Для профессионалов .NET 3.0" - http://depositfiles.com/files/4594993

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

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

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

К таким могу отнести:
Мост (Bridge) про этот паттерн до сих пор спорят архитекторы и не могут приди к единому мнению -- в сад!
Строитель (Builder) сам не использовал -- не сталкивался с объектами требующими сложного конструирования.
]Комманда -- в большинстве случаев приводит к усложнению кода
Но в случаях когда она действительна нужна она незаменима, только вот трудновато новичку их определить. Я благодарин моему другу, что он отговорил меня его использовать в моем проекте (а было ох какое желание и тогда я думал, что он очень грамотно ложиться на задачу).
Цепочка обязанностей (Chain of Responsibility) -- см. команда, только попроще распознать нужен ли он тебе.
... 
Дописал до сих пор и понял, что все эти паттерны (кроме Моста, этот вообще жесть -- запутаться в нем раз плюнуть) при использовании не к месту всегда приводят к усложнению кода. Т.о. самая главная задача определить -- а оно тебе надо? Поэтому начинающему архитектору лучше о них не знать 

Продолжу перечисление:
Компоновщик (Composite), Интерпретатор (пример сложного паттерна, но его врятли начинающий рискнет использовать), Медиатор (лучше сразу MVC, MVP...), Посетитель (Visitor).

В противовес, паттерны которые должен знать каждый! разработчик:
Адаптер, Фасад, Итератор (хотя и встроен в современные языки, многи не понимают что это и зачем), Хранитель (Memento), Наблюдатель (Observer) (грамотно реализован в .Net с поможью событий), Синглтон, Состояние (State), 

Более сложные (знать не обязательно, но желательно): 
Фабричный метод, Декоратор, Прокси (Proxy)


Вот такое мое ИХМО.

Это сообщение отредактировал(а) ivashkanet - 11.4.2008, 09:17

Еще раз подчеркну:

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

У меня как раз Command всегда все упрощал. Это хороший способ инкапсулировать все, что относится к одному действию. Кроме того, этот паттерн позволяет строить иерархию комманд (Composite) или под-команды (когда одно действие состоит из нескольких более простых действий).

Добавлено через 2 минуты и 34 секунды

По-сути любая иерархичная структура реализует этот паттерн.

Хороший пример использования - обход дерева файлов проекта при компиляции.

Добавлено через 6 минут и 37 секунд

Извините, этo я погорячился.

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

И ты считаешь это не сложный пример?

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

ivashkanet, Во всем согласен. Простo я не в том ключе прочитал Ваш пост.

Добавлю  свое ИМХО по аналогии Вашего.

Должны знать: Factory, Factory method, Decorator, Adapter, Facade, Iterator, Proxy, Command, Memento, Observer, Composite, Mediator(?)

Необязательно: Chain of responsibility, Bridge, Builder, Visitor, (Mediator)


Собственно, Mediator - слишком пространственный паттерн. Наверняка его применяли все, простo не давали себе в этом отчет.

А вот и не правда  Для этого случая больше подходит прототип (один из обязательных паттернов).

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

В ГоФ-е дают пример про RTF документ, который билдиться из разных источников: обычного текста, TeX-файла, ...

Добавлено через 13 минут и 32 секунды
И еще, немного пересмотрел свой список (  ) исключив из него сложные паттерны, но которые тяжело использовать не там где надо 
Это например Компоновщик (Composite). О нем хорошо бы просто знать.
Потому что для работы с графикой (нарисовать три линии, квадратик, а внурти треугольник  ) он нужен просто как воздух.

Все же позвольте мне с Вами не согласиться.

В моем примере prototype и builder одинаково применимы. Я считаю, что билдер подходит больше из-за полного отсутствия разницы между классами. Потом некоторый customizing объектов все же необходим, так что после Clone()-а все равно надо будет менять какие-то свойстава. Хотя в обшем и прототип тут тоже сойдет и фактори.