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

Если про паттерны то, имхо, лучшая это книга "банды четырех"
GoF
Если шаблоны C++ то
Влиссидис и Джоссатис - "Шаблоны C++. Справочник разработчика" (но книга не для чайников) 

Это сообщение отредактировал(а) MAKCim - 29.5.2006, 21:11

FurryFreeman, а поискать? Я про четыре книги расписывал в каком порядке их читать нужно. GOF - яно не лучшая для начала 

зато почти что классика
и вообще, что значит для начала? Человек вообще не знаком с ООП? Тогда ему про паттерны вообще читать пока не надо. А если знаком, то все термины этой книги будут понятны (интерфейс, реализация, инстанцирование, объект, ...) и читать ее будет, имхо, не так уж и сложно. Зато там изложено все четко, лаконично, с примерами реальных приложений и т. д 

MAKCim, по GOF я не смог разобратся с паттерном "Мост". Эта книга неплоха в качестве справочника 

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

В чем именно? 

FurryFreeman, прочитай эту тему от начала до конца: Паттерны проектирования, (книги, ресурсы, библиотеки) 

Всем спасибо, буду прокуривать.  

Что означает в нем "отделение интерфеса от реализации" и т.д. Очень "сумбурно" написано.

P.S. Ссылку выдал хорошую
 

Отделение интерфейса от реализации означает, что иерархия интерфейса строится "параллельно" иерархии реализации. Цель - дать возможность обеим иерархиям изменяться независимо, без взрывного роста количества классов, которое получилось бы при простом наследовании. В данном случае под реализацией подразумевается не полная реализация интерфейса, а какой-либо его части (которых может быть не одна). 
Не буду нарушать традицию и приведу пример иерархии графических фигур. Базовый класс IShape, производные классы IPoint, ICircle, IRect, etc... Обычно приводится пример реализации рисования, который может быть реализован с помощью разных библиотек, которые нужно уметь переключать... 
Но я приведу другой пример: способы хранения объектов в памяти. Проще всего представить себе контейнер умных указателей на базовый класс IShape. Но если объектов тыщи и мильоны, как-то начинает душить жаба... Даже загрузить все это счастье из файла - уже проблема (пока насоздаешь столько динамических объектов...). Тем более, когда понимаешь, что в динамическом виде эти объекты нафиг не нужны сразу все - реально-то пользователь интерактивной программы работает с несколькими. И за сеанс работы все тыщи явно не окучит. Но некоторые функции от всех объектов все же требуются: скажем, уметь рисоваться и отвечать на какие-нибудь запросы, не изменяющие их состояния. 
Отсюда приходим к идее: реализуем-ка объекты двумя способами: облегченная реализация, выполняющая только read-only запросы, и полная реализация. Облегченная реализация может быть сделана в виде оболочки над упакованной структурой, прочитанной из файла "большим куском" (т.е. не нуждающейся в конструкторе). А для полной потребуется честный динамический объект.
Если мы попробуем унаследовать обе реализации от наследников IShape, что кажется естественным... (не знаю, мне так не кажется, но в книгах пишут, что должно...  ) ... Короче, классы начнут плодиться как тараканы. А если потребуется еще какой-нибудь тип хранения (ну не знаю, какой-нибудь удаленный доступ), то вообще впору застрелиться. Однако, построив отдельную иерархию реализаций (не наследуя от IShape), а просто храня в конкретном классе IShape указатель на реализацию, мы эту проблему красиво решим. Это и есть Мост. Правда, в моем примере используется еще и паттерн прокси, но это нормально - паттерны в чистом виде в программах редко водяться. 

исчерпывающий ответ    

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

Т.е., если кто не чувствует позвоночником, какая это ВЕЩЬ, не расстраивайтесь, просто примите к сведению. Даже применять не надо, если что-то кажется излишне навернутым. Но придет время, и вы наверняка столкнетесь с проблемой, не решаемой с помощью if-else... И вот тогда придет время паттернов... 

Earnest, спасибо, мне это уже бъяснять не надо. 

А можно поподробней и с рисунками? Уж очень интересно!

Куда уж подробнее   
Читай GoF