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

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

Это сообщение отредактировал(а) Alek86 - 10.11.2007, 23:49

вот тут довольно толково про декоратор

http://www.insidecpp.ru/patterns/decorator/

думаю, что твои проблемы как раз о томже

вах, какой гон на декоратор...

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

дело в том, что в той реализации паттерна, что я знаю для его реализации НЕОБХОДИМО иметь интерфейс

такое ощущение, что автор того гона просто не читал Design Patterns 

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

скорее ты не читал. Твоё описание скорее похоже на Proxy

[B]

да, должно. от интерфейса. а декорируемый класс является полем, потому второй проблемы нет.
я привык к такой схеме:



изменение интерфейса, конечно, скажется на обоих классах, но именно эту проблему я и хочу свести к минимуму. ведь очевидно, что при добавлении новой фукнции C2 должен просто делегировать реализацию от m_pC, при удалении фукнции C2 это должно волновать ТОЛЬКО если он в ней что-то менял по сравнению с m_pC, то же и при изменении имени+параметров функции.

Добавлено @ 12:30

тут был бред, удалил

Это сообщение отредактировал(а) Alek86 - 11.11.2007, 12:41

если я правильно все понял, то именно это и есть главный недостаток Decoratora, который ты хочешь обойти, но обойти его неполучится, ибо Decorator ОБЯЗАН реализовывать весь интерфейс (что собственно и является минусом). Можно конечно наследовать класс декоратора от class C2 , а не от базового, но тогда смысл декоратора пропадает т.к. его предназначение избавиться от большого количества подклассов (к чему приведет такое наследование), и использовать этого декоратора для добавления функциональности к ЛЮБОМУ классу иерархии.
Кстати 

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

Это сообщение отредактировал(а) Fazil6 - 11.11.2007, 13:37

да, тут я, похоже, лажанул 





а вот так?


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

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