хотя это и не только для жавы,
перерыл гугль с описанием этого патерна, прием давно известный в качестве параметра принимаеться объест , 
потом вызываються методы в главном объекте, обычный wrapper. Лет 20 назад а то и 30 в MainFrame были callback функции,
и они вызывались из главной , в С были и есть поинтеры на функцию, ну сегодня все работают объектно ну и что? в чем это паттерн заключаеться?
в том он применяеться на уровне интерфейсов, так  интерфейс это и есть класс (чисто виртуальный) , только в жаве его по особому выделили ,

мое ощущение что теорию на голоv месте изобрели , причем непонятно зачем .

sergioK, а кто говорит, что его вчера придумали? Главная заслуга Гаммы со товарищи (кстати, самой их книжке уже 15 лет) не в том, что они что-то придумали, а в систематизации большого объема программистских практик, подходов и решений, накопленного мировым софтверным сообществом за долгие годы разработки не самых тривиальных систем, сопровождавшихся набиванием шишек и наступанием на грабли — и все это с целью предостеречь от аналогичных шишек и граблей последующие поколения программистов. И если слово интерфейс звучит для вас сегодня буднично и естественно, то не забудьте сказать спасибо Гамме, а также Вирту, Страуструпу и другим чувакам, усилиями которых языки программирования прошли неблизкий путь от Фортрана и Алгола до сегодняшних OOP-языков с RAD-поддержкой и развитыми IDE.

Это не теория на голом месте. Это описание best practices. Ну, не всегда best, но это отдельный разговор. Как правильно заметил Stampede, Гамма сотоварищи просто систематизировали то, что уже применялось, причем часто задолго до них.

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

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

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

А что делать когда один и тот же шаблон у разных людей называеться по разному?
У меня есть масса кода  где все эти шаблоны применяються немного по другому, так как 
определить это bridge, adapter wrapper, или давать им какие то другие названия, 
слышал не один раз что wrapper это decorator, Custom delegate, embedded , callback Interface.
Adapter часто называют Converter иногда интерпролятор, 
И где тут систематизация? всех на винград,ру слать    или 
к Гамме 

Это сообщение отредактировал(а) sergioK - 17.12.2010, 13:23

А Причем сдесь Вирт он же создатель структурного стиля, (без go to)
Ну а имя  Гранди Буч кому-нибудь что-то говорит,?
 читав его 10-11лет назад мне казалось чем то абстактным, далеким от реальности,
 прочитав его в сейчас вдруг понял , что 
фраза жава напрещает двойное наследование - это как минимум не точно,
а так же то что в С объектов не было, и многое другое ,

Тоже самое, если один человек называет букву "А" буквой "Б". Слать к азбуке. 


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

Это на самом деле большая проблема. Например, для кого-то Value Object - это почти то же, что и DTO, но Мартин Фаулер определил это название под другой шаблон; для кого-то существует только два вида Фабрик - Фабричный Метод и Абстрактная Фабрика, а кто-то вводит еще и Обычную Фабрику; где-то употребляют название Action, а где-то - Command; еще из проблемных названий - MVC & Model2 (MVC2), некоторые выделяют его в отдельный шаблон, другие продолжают все это называть просто MVC. Главное в таких ситуациях - знать все эти термины и, что они, порою, значат разные вещи. Затем нужно поделиться с окружающими своими знаниями и определить тот вариант, который вы будете использовать в своем окружении. 
Еще есть моменты, когда шаблоны ну очень похожи, так Proxy порой не отличим от Decorator'a. В таких ситуациях помогает а) Доскональное знание шаблонов; б) Не замарачиваться 
Очень сложные и нудноватые книги, не советовал бы читать их новичкам. Если говорить все о тех же шаблонах, то в Head First Design Patterns все намного понятней, и читается быстрей.

Это сообщение отредактировал(а) Старовъръ - 17.12.2010, 23:08

[QUOTE=Старовъръ,17.12.2010,  23:03]
Так может эффективнее обьяснить тот самый шаблон не называя его конкретно, ведь досконально все равно знать не будешь, или выучишь ,а через какое то время забудешь,
а название пускай каждый применяет какое ее нравиться , сердцу как говориться не прикажешь   ,

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

B,T.W.

у Буча всем известный патерн оbserver называеться acthor

Это сообщение отредактировал(а) sergioK - 18.12.2010, 04:57

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

Это сообщение отредактировал(а) Старовъръ - 18.12.2010, 10:51

Не согласен доскональное знаниние шаблонов это и есть кодировка, ну вызубрил и дальше ?? профессионал умеет увидеть нужный шаблон в нужный момент,
это уже скорее искуство ,
только работодатели не всегда это понимают 
IMHO

Это сообщение отредактировал(а) sergioK - 18.12.2010, 21:04

Что значит вызубрил? В моем понимании доскональное знание - это умение применять в разных ситуациях разные вариации шаблонов, отличать их от других шаблонов и уметь довести до ума коллег почему он уместен в том или ином случае.
Без знания шаблонов ты будешь 10 лет бить себе голову, как и сказал Skipy, а потом придешь к тому же, что другие за год смогли освоить, ознакомившись предварительно с шаблонами.

Кстати, насчет зубрежки шаблонов. Видел новичков, которые говорили себе: не буду браться за практические задачи, пока не изучу досконально теорию (design patterns в том числе). Они так и оставались новичками. IMHO - сделать неоптимальный проект с наивными решениями - это неизбежная ступенька на пути к мастерству. Design patterns, как впрочем, и другие подходы лучше всего воспринимаются уж после того, как набил себе шишку, ломясь в открытую дверь, или потерял кучу времени, чтобы придумать то, что давно всем известно. Помню в свое время начал более или менее понимать объектный подход только тогда, когда пару раз код стал неуправляемым.

архитектурном развязывании слоев приложения ?
А это что за зверь ? 

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

 Фильм про ментов помнишь ? Когда капитан Дукалис выходит после комиссии, его Ларин спрашивает ,
 "Толян чего такой грусный, не здал что-ли ? " . На что тот отвечает "Какая разница сколько ствол весит ,если стрелять не умееешь? "

  

Это сообщение отредактировал(а) sergioK - 20.12.2010, 16:19

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

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

P.S. Я еще несколько лет назад читал нашим разработчикам лекцию об архитектурном развязывании слоев приложения. Сам это весьма неплохо умею делать. И только при написании статьи о модульном дизайне я вычитал правильное название - dependency inversion. 

P.P.S. А если меня спросить о шаблонах стандартной Java - я всех даже не назову, не то, что досконального описания не дам. И что? Это мне не позволяет их всех применять?

P.P.P.S. Был у меня разработчик. Он шаблоны знал очень хорошо. Вот только его код понять было невозможно - за деревьями леса не было видно. Почему? Да потому, что мышлением он не отличался. И применял шаблоны "в лоб", по книжке.

И напоследок. Почитайте вот это: http://russian.joelonsoftware.com/Articles...eNakedChef.html. Очень хорошо написано, что такое шаблоны и для чего они нужны. И для кого они нужны.

Это сообщение отредактировал(а) Skipy - 20.12.2010, 11:35

Хорошая статья. Спасибо.