Comments 7
К соажалению, вы упустили важнейшую деталь этого паттерна — декоратор _динамически_ меняет поведение без внесения _изменений_ в сам класс, а у вас наследование заменено трейтом инджектируемым в класс.
$window = new StandartWindow();
$windowWithCoolScroll = new DecoratorCoolScrol($window);
$windowWithCoolScroll->render();
$windowWithoutScroll = new DecoratorWithoutScrol($window);
$windowWithoutScroll->render();
$window = new StandartWindow();
$windowWithCoolScroll = new DecoratorCoolScrol($window);
$windowWithCoolScroll->render();
$windowWithoutScroll = new DecoratorWithoutScrol($window);
$windowWithoutScroll->render();
Это мое личное мнение, но все же типажи называть миксинами несколько некорректно.
Меня бы больше интересовал реальный пример, когда декораторы могут упростить работу. Ибо пример в статье сильно надуманный. Есть конечно задачи, при которых динамическое добавление функционала может оказаться полезным, но не обязательным.
Меня бы больше интересовал реальный пример, когда декораторы могут упростить работу. Ибо пример в статье сильно надуманный. Есть конечно задачи, при которых динамическое добавление функционала может оказаться полезным, но не обязательным.
Насчет надуманных примеров согласен. Реальные примеры требуют отдельного описания.
Без описания примеров, где может пригодиться этот паттерн, реальных примеров, где декоратор упрощает жизнь, ценность этой статьи снижается до минимума.
Ну это сильно сложное, и наверное неправильное использование декоратора в РНР. Як конечно (слава Богу) не РНР-шник, и как там с интроспекцией не знаю, но РНР ведь динамически типизованный, и там все вообще просто должно быть — как в Питоне. А в Питоне декорация — проще некуда.
Sign up to leave a comment.
Реализация шаблона проектирования декоратор на PHP