вопрос, опять же, в самом названии.
Для применения паттерна Decorator к контролам требуется единый интерфейс для всех моих контролов. А, как я посмотрел, Control в шарпе является реализацией многих интерфейсов, большинство из которых мне не очень понятны :(

Есть ли в шарпе способ использовать декоратор иначе, чем самому создавать интрефейс для для контролов?

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

В Шарпе все контролы имеют один общий интерфейс (в понятии архитектуры) доставшийся им от их родителя -- класса Control. Поэтому легко применить этот паттерн.

не очень понял :(

если есть у меня кнопка (Button) и нужно сделать:
1) кнопку, которая "светится" при наведении на нее мышкой
2) кнопку, которой можно менять цвет правой кнопкой мыши


в связи с этим несколько вопросов:

1. Как требуется реализовать подобное?



так?
то есть нужно самому перезаписать все методы кнопки, чтобы они работали, как именно у кнопки, что находится в m_Button (с помощью делегирования), причем нужно не забыть ни единого, иначе и никаких ошибок не будет и "кнопка" будет не всегда вести себя, как та, что в m_Button.


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


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

Это сообщение отредактировал(а) Alek86 - 19.9.2007, 11:48

Если у тебя только Button (или Button и ещё несколько контролов, но не много) и всего две функциональности, то лучше сделать двух наследников кнопки, которые будут работать так как тебе это нужно!

Декоратора, вообще, нужно использовать только там где без него нельзя. Потому, что этот паттерн всегда влечёт за собой усложнение конечного кода.

Да. Только я не не совсем уверен что скрывается под словом "реализация". У каждого она будет своя.

Это недостаток Декоратора и от него никуда не денешься. Тем более тобою выбран объект с очень богатым интерфейсом.
 
В VS 2005 пишешь "override", нажимаешь пробел и смотришь что осталось ;-)

P.S. Есть ещё такое понятие как динамический прокси (гугл дал ссылку только на жаву, но суть от этого не меняется) . Что-то типа такого можно попытаться применить в данном случае.

ну, насчет "лучше сделать двух наследников кнопки" не совсем согласен так как 100% понадобится кнопка, что умеет делать и то и другое


насчет остального спасибо за ответ 

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


блин. пока писал это, сомнение закралось...
может, есть все же в шарпе механизм, с которым даже ivashkanet не знаком?

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

И что бы этот интерфейс содержал? То же самое, что и Button. 
Тем более ты используешь методы класса Control (доставшихся Button по праву наследования).

можно узнать, каким образом? с помощью копипаста?



именно. но повторю то же самое:
1. но интерфейс не содержал бы данных, то есть ничего не весил (в моем примере я наследую LightButton от Control только для того, чтобы унаследовать его публичные методы, а все то лишнее, что он с собой принесет - лишь балласт)
2. наследуясь от интерфейса я обязан реализовать все его "паблики". наслдуясь же от класса я ничего подобного делать не обязан, за что могу и поплатиться

разве это не достаточные причины для того, чтобы в языке был продуман механизм интерфйсов контролов?


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

  
Тоже вариант

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

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

пойду письмо сочинять