Шаблон "декоратор": Почему нам нужен абстрактный декоратор? [дубликат]

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

(Немного поздно ответить на ваш вопрос ..)

Я также потратил довольно много времени, чтобы попытаться найти ответ. В моем случае неконкретный декоратор расширяет класс, который нужно декорировать («декоратор»), вместо интерфейса, общего как для декоратора, так и для декоратора.

После прочтения из разных источников мне кажется, что помимо того, что сказал Тванфоссон , причина того, что конкретные декораторы расширяют абстрактный или более общий декоратор, заключается в том, чтобы мы не повторяли код "делегирования" снова и снова.

[Beverage]<———————[(abstract) CondimentDecorator]<—————[Milk]
[decoree ]——————<>[ adds code to efficiently    ]
                  [ forward calls to decorated  ]<—————[LemonJuice]
                  [ instance of Beverage        ]

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

Надеюсь, я был ясен ..: -S

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

В PHP 5.3.2 (да, я знаю, что ваш вопрос связан с Java), тем не менее, должна быть возможность динамически перехватывать все вызовы методов и перенаправлять их все, при этом декоратору не нужно знать, какие методы вызываются ( тем не менее, не очень эффективным способом из-за необходимости использования Reflection API). Думаю, это уже возможно в Ruby и других языках.

PS: Это мой первый ответ в SO! ^ _ ^

Я задавался тем же вопросом. Возвращаясь к источнику, GOF Design Patterns, я вижу следующее в разделе 'Implementation' в главе Decorator:

"Omitting the abstract Decorator class. Нет необходимости определять абстрактный класс Decorator, если вам нужно добавить только одну ответственность. Это часто бывает, когда вы имеете дело с существующей иерархией классов, а не разрабатываете новую. В этом случае вы можете объединить ответственность Decorator за пересылку запросов к компоненту в Concrete Decorator."

Так что, по крайней мере, в этом случае, кажется, что GOF с вами согласен :-)

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

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