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

[jonjonson]

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

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

И ещё подумайте о том, что тема топика совсем в другом, а ваш вопрос никакого отношения к нему не имеет...

 

[StUV]

Вроде тут хорошо подходит паттерн декоратор (недавно только их начал изучать и пытаться применить).

ключевой момент флейма - неправильно поставленный вопрос тредстартером
вопрос должен был звучать - "какой паттерн лучше подходит?"

зы: флейм мог бы быть веселее

 

[Crazy]

jonjonson, я вижу стоило повторить вопрос. Поскольку твой ответ к моему вопросу не имеет никакого отношения.

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

И ещё подумайте о том, что тема топика совсем в другом, а ваш вопрос никакого отношения к нему не имеет...

Который мой вопрос? Который я задал или на который ты ответил? Я вижу в твоих высказываниях прямое противоречие и это мешате мне постигать Великий Смысл этого топика. Это делает мою жизнь ничтожной и лишенной смысла. И гасит свет в конце моего тоннеля.

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

А я-то, наивный, думал, что проблема уже поставлена:

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

Нет, я, разумеется, не настаиваю. Но если ты сам хочешь показать эту реализацию -- я с удовольствием посмотрю. Вроде как crocodile2u уже изъявлял желание посмотреть на код.

-~{}~ 29.05.07 13:22:

Автор оригинала: StUV
вопрос должен был звучать - "какой паттерн лучше подходит?"

...а это, IMHO, совсем страшный вопрос. Страшнее может быть только один: "а какой паттерн здесь применен?"

P.S. В реальной жизни видел, как два программера спорили, какой паттерн применить: Adapter или Factory. Забрызгали друг друга слюнями и пошли писать каждый свой код. Код получился идентичный с точностью до имен переменных и методов.

-~{}~ 29.05.07 13:23:

Автор оригинала: StUV
зы: флейм мог бы быть веселее

Ну эт' мы обеспечим...

 

[crocodile2u]

вопрос должен был звучать - "какой паттерн лучше подходит?"

...а это, IMHO, совсем страшный вопрос. Страшнее может быть только один: "а какой паттерн здесь применен?"

Crazy
Вот! Я про нечто подобное еще хотел сказать - в самом начале, когда приводил свое решение с наследованием (StUV, я, кстати, там говорил о том, что это вовсе не декоратор, а всего лишь наследование)! Паттерны нужны только для того, чтобы облегчать дискуссию. В хорошей архитектуре паттерны возникают сами по себе, и не нужно задумываться о том, "какой паттерн здесь применить". Просто в один момент обнаруживаешь, что структура классов в какой-то части проекта сильно напоминает диаграмму того или иного паттерна. И сами GoF, Martin Fowler & Co говорят о том, что они НЕ придумали ничего нового - просто каталогизировали стандартные решения, которые применяются уже давно. Шаблоны НЕ должны становиться самоцелью!

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

 

[Crazy]

Автор оригинала: crocodile2u
И докажи всем, что такая реализация имеет право на жизнь.

Я предлагаю немного более мягкий вариант: "и обсудим, насколько уместна такая реализация".

P.S. Комментарий к неотквоченному: кто-то из мудрых сказал, что самое страшное -- это когда design patterns начинают превращаться в code snippets...

 

[dark-demon]

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

и получается прототипное ООП

 

[StUV]

crocodile2u

StUV, я, кстати, там говорил о том, что это вовсе не декоратор, а всего лишь наследование)!

сорри, остальная часть топа затмила вышесказанное =)

и не нужно задумываться о том, "какой паттерн здесь применить"

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

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

зы: кажется, это был полный оффтоп =)
ззы: кажется, тредстартер проблему давно решил

 

[zerkms]

и получается прототипное ООП

м?

 

[dark-demon]

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

правда в прототипном ООП понятие "класс" только мешается...

 

[whirlwind]

Декоратор позволяет изменять поведение экземпляра в реальном времени (т.е. по ходу работы программы). Он подходит для внесения изменений в "точки входа", т.е. в методы, с которыми взаимодействует пользовательский класс. С помощью декоратора нельзя кардинально изменить поведение декорируемого класса, это потребует разработки декорируемого класса именно с упором на последующую декорацию, что практически не имеет смысла (паттерн ради паттерна). Декораторы следует использовать в тех случаях, когда хочется сохранить оригинальный код в первозданном виде (например при рефакторинге гавнакода, когда нет уверенности что если "здесь" дернуть, то "там" не отвалится).

 

[jonjonson]

Да. Признаю, я был не прав со своими примерами. :-\