Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > .NET для новичков > как прикрутить Decorator к контролам?

Автор: Alek86 19.9.2007, 08:54

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

Автор: ivashkanet 19.9.2007, 09:57

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

Автор: Alek86 19.9.2007, 11:32

не очень понял :( если есть у меня кнопка (Button) и нужно сделать: 1) кнопку, которая "светится" при наведении на нее мышкой 2) кнопку, которой можно менять цвет правой кнопкой мыши в связи с этим несколько вопросов: 1. Как требуется реализовать подобное? Код class LightButton : Button { //  ... //  реализация     Button m_Button; } class ColorButton : Button { //  ... //  реализация     Button m_Button; } так? то есть нужно самому перезаписать все методы кнопки, чтобы они работали, как именно у кнопки, что находится в m_Button (с помощью делегирования), причем нужно не забыть ни единого, иначе и никаких ошибок не будет и "кнопка" будет не всегда вести себя, как та, что в m_Button. 2. Если описанное в первом вопросе не полный бред, то как узнать, что я переписал ВСЕ методы и свойства, присущие кнопке? 3. Если первые два вопроса совсем уж непонятны, то как бы вы реализовали эти кнопки с помощью декоратора?

Автор: ivashkanet 19.9.2007, 13:39

Цитата(Alek86 @  19.9.2007,  11:32 ) если есть у меня кнопка (Button) и нужно сделать: Если у тебя только Button (или Button и ещё несколько контролов, но не много) и всего две функциональности, то лучше сделать двух наследников кнопки, которые будут работать так как тебе это нужно! Декоратора, вообще, нужно использовать только там где без него нельзя. Потому, что этот паттерн всегда влечёт за собой усложнение конечного кода. Цитата(Alek86 @  19.9.2007,  11:32 ) так? Да. Только я не не совсем уверен что скрывается под словом "реализация". У каждого она будет своя. Цитата(Alek86 @  19.9.2007,  11:32 ) причём нужно не забыть ни единого Это недостаток Декоратора и от него никуда не денешься. Тем более тобою выбран объект с очень богатым интерфейсом. Цитата(Alek86 @  19.9.2007,  11:32 ) я переписал ВСЕ методы   В VS 2005 пишешь "override", нажимаешь пробел и смотришь что осталось ;-) P.S. Есть ещё такое понятие как динамический прокси (гугл дал http://www.ibm.com/developerworks/ru/library/j-jtp08305/ только на жаву, но суть от этого не меняется) . Что-то типа такого можно попытаться применить в данном случае.

Автор: Alek86 19.9.2007, 15:03

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

Автор: ivashkanet 19.9.2007, 15:10

Цитата(Alek86 @  19.9.2007,  15:03 ) так как 100% понадобится кнопка, что умеет делать и то и другое Тогда бы я подумал и все равно использовал бы третий класс   Вот если бы мы имели 4 (и больше) претендента на декораторы и были бы возможны (%-ов на 90) их комбинации, то я бы обратился к декорированию. Цитата(Alek86 @  19.9.2007,  15:03 ) так бы унаследовался от какого-то IButton. И что бы этот интерфейс содержал? То же самое, что и Button.  Тем более ты используешь методы класса Control (доставшихся Button по праву наследования).

Автор: Alek86 19.9.2007, 16:23

Цитата(ivashkanet @  19.9.2007,  15:10 ) Тогда бы я подумал и все равно использовал бы третий класс   можно узнать, каким образом? с помощью копипаста? Цитата(ivashkanet @  19.9.2007,  15:10 ) И что бы этот интерфейс содержал? То же самое, что и Button.  именно. но повторю то же самое: 1. но интерфейс не содержал бы данных, то есть ничего не весил (в моем примере я наследую LightButton от Control только для того, чтобы унаследовать его публичные методы, а все то лишнее, что он с собой принесет - лишь балласт) 2. наследуясь от интерфейса я обязан реализовать все его "паблики". наслдуясь же от класса я ничего подобного делать не обязан, за что могу и поплатиться разве это не достаточные причины для того, чтобы в языке был продуман механизм интерфйсов контролов? ЗЫ. Со стороны может покааться, что я затеял спор ради спора, но это не так, я всего лишь хочу "докопаться" до истины, так что буду только рад, если мои аргументы опровергнут или вообще как-то отреагируют

Автор: ivashkanet 19.9.2007, 16:40

Цитата(Alek86 @  19.9.2007,  16:23 ) с помощью копипаста?    Тоже вариант Цитата(Alek86 @  19.9.2007,  16:23 ) разве это не достаточные причины для того, чтобы в языке был продуман механизм интерфйсов контролов? Точно! Напиши об этом в Майкрософт ;-)  Не думаю, что из-за сложностей с декорированием стоит это делать.  Тем более, что существующая структура, несомненно, более выигрышная ввиду того, что не нужно реализовывать каждый раз код с нуля.

Автор: Alek86 19.9.2007, 18:15

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)