Меню
Что нового?

Вопрос по паттерну "декоратор"

Sanchez

Новичок
Вопрос по паттерну "декоратор"

Привет, делаю тут для себя небольшой набор заготовок, дабы максимально упростить создание новых сайтов..
Сделал класс, который рисует один элемент типа <textarea>, ну там со всем содержимым и т.п.
Понадобилось сделать еще для него обертку - аналогичную текстарею, но еще с FckEditor - редактором. Вроде тут хорошо подходит паттерн декоратор (недавно только их начал изучать и пытаться применить). Но.. Получается, что мне в новом классе нужно заместить ВСЕ методы родительского, даже если я не хочу их переделывать? Я уж молчу про атрибуты - их вообще никак не заместишь, тоже для них делать метод-обертку?
 
zerkms

zerkms

TDD infected
Команда форума
в пхп "универсальный" декоратор легко реализуется с помощью __call

Я уж молчу про атрибуты - их вообще никак не заместишь, тоже для них делать метод-обертку?
Нажмите для раскрытия...
декоратор ничего не должен знать о свойствах. если получается что должен - значит ты должен "спрятать" их за геттерами/сеттерами
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
Sanchez
А ведь можно просто унаследовать FckEditor от textarea...

пример кода :
PHP: 
<?php
class Textarea {
    protected $_cols;
    protected $_rows;
    function draw()
    {
         ?><textarea cols="<?=$this->_cols?>" rows="<?=$this->_rows?>"></textarea><?php
    }
}
class FckEditor extends Textarea {
    function draw()
    {
         ?>FckEditor JAVASCRIPT HERE<?php
          parent::draw();
    }
}
?>
Таким образом, как я понимаю, ты решишь проблемы с методами и свойствами одним махом. Шаблоны ради шаблонов - зло.
 

Sanchez

Новичок
Да я в итоге так и сделал через 5 минут после написания сообщения - переделал в обычное наследование.
Мне в PHP вообще не очень понятен смысл этого паттерна, в чем его преимущество перед обычным наследованием. В книге сказано, что преимущество в том, что можно _динамически_ подменять объект, таким образом добавлять какие-то внешние примочки во время выполнения. В PHP же фактически программа выполняется один раз, а реакция на действия пользователя - по сути новое выполнение программы.
 
zerkms

zerkms

TDD infected
Команда форума
ты рассматривай не конкретный запуск, а архитектуру в целом
с помощью декораторов, например, можно удобно осуществлять кеширование
 
jonjonson

jonjonson

Охренеть
Sanchez, декоратор и простое наследование это разные вещи. Класс декоратор не расширяет другой класс, а тупо эксплуатирует его. Декоратору нужны свойства и методы какого либо класса. Он их не реализует заново и не наследует. Он тупа получает нужное и сверху делает обёртку, для интеграции используемого в своём поведении.

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

jonjonson

Охренеть
crocodile2u, могу привести пример из книги издательства O'Reilly "Head First Design Patterns" об уточках ;)

Скажем у уточек есть бехавиор (поведение), как-то: издавание звуков типа кря-кря и навык плаванья. Так вот, уточка это поведение не реализует в классе утки, а координирует (или всё таки использует?). Она является декоратором для кряканья и плаванья, реализуемых другими классами.

Такой пример устроит? :)
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
Расскажи об этом примере уточке...

А меня устроит диаграмма классов - как бы ты реализовал класс формы и ее элементов с использованием декоратора.
 
jonjonson

jonjonson

Охренеть
crocodile2u, кто-то утверждал, что нужно реализовывать класс формы через декоратор? Или у нас просто плохое настроение и мы не хотим никого воспринимать? :-\

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

Если же вы намекаете, что мой пример больше под компоновщик подходит, так то не правда. И форма, и уточка - это не контейнер. Это сущности сами по себе со своим внутренним механизмом.
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
кхм. я все-таки отказываюсь понимать, как это форма может являться декоратором для окна ввода...

"Окно ввода - составная часть формы" - эту фразу я понимаю.

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

И кстати, при чем тут вообще фабрика? о ней-то кто хоть слово здесь сказал?

-~{}~ 29.05.07 11:56:

crocodile2u, кто-то утверждал, что нужно реализовывать класс формы через декоратор? Или у нас просто плохое настроение и мы не хотим никого воспринимать? :-\
Нажмите для раскрытия...
Чтобы не быть голословным:

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

jonjonson

Охренеть
crocodile2u, всё дело в том, что бы texarea была изменена хоть на сколько-то классом формы? А то что она будет заключена между двух тегов form (открывающего и закрывающего) и при этом добавляющих ей новую смысловую нагрузку? Ещё можно JavaScript привязать к textarea, имеющий смысл для формы, но при этом расширяющий функциональность textarea. Так понятнее?
 
StUV

StUV

Rotaredom
jonjonson
crocodile2u
чесссно говоря, из вашего диалога так и не понял, кто при чем остается ;)
 
crocodile2u

crocodile2u

http://vbolshov.org.ru
StUV
Мое мнение: описывать взаимоотношения формы и окна ввода с помощью декоратора - извращение.

Мнение jonjonson - что декоратор в этом случае хорошо подходит.

Теперь понятно?
 
StUV

StUV

Rotaredom
хм
crocodile2u
имхо, твой пример до декоратора "не дотягивает" - простое наследование

а пример jonjonson (к сожалению без кода - только на словах) - имхо, просто пример агрегации/использования (если б в пхп были дружественные классы - первый пример был бы еще и корректным)

в общем - предложены два типа решений, к декоратору особого отношения не имеющие...

я в чем-то не прав ? ;)
 
jonjonson

jonjonson

Охренеть
Мнение jonjonson - что декоратор в этом случае хорошо подходит.
Нажмите для раскрытия...
Подтвердить цитатой из моего текста можешь?
Приведи свой более удачный пример декоратора.

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

Crazy

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

По сравнению с неприменимым вариантом любой пример из книжки будет более удачным. Книжки подсказать?
 
jonjonson

jonjonson

Охренеть
Crazy, перечти топик, а потом давай "ценные" указания ;)

Пример желающие могут глянуть в 12 главе
PHP Architects Guide to PHP Design Patterns от Jason E. Sweat

И ещё одно замечание, декорирование не должно восприниматься только как "изменение выводимых данных".
 
Войдите или зарегистрируйтесь для ответа.
Сверху