Чтобы использовать их пример, у вас может быть класс окна, который можно прокручивать и / или окрашивать его границы различными способами (или не рисовать вовсе).Если бы вы использовали наследование для охвата всех этих функций, вам понадобился бы один подкласс для каждой возможной комбинации функций (без рамки, без прокрутки, без рамки, без прокрутки, без рамки, рамки и прокрутки и т. Д.).Это негибкий кошмар обслуживания, так как вы добавляете больше функций, потому что количество классов резко увеличивается.
Главное, что они здесь делают, это то, что вы можете использовать либо шаблон стратегии, либо шаблон декоратора, чтобы лучшерешить эту проблему.У вас может быть класс Window, который инкапсулирует объект стратегии прокрутки и объект стратегии границы.Или вы можете взять свой объект Window, обернуть его внутри граничного декоратора и обернуть его внутри прокручиваемого декоратора.
Но вы совершенно правы в своем понимании;это два разных шаблона проектирования с разными характеристиками, которые ведут к разным приложениям.С Decorator, Компонент не знает агента, который добавляет функциональность ... и поэтому вы склонны в конечном итоге строить вокруг существующего класса компонента.Со Стратегией все наоборот, поскольку Компонент использует (и, следовательно, знает) агентов для выполнения различных задач - эти агенты обычно не знают о своих управляющих Компонентах.