Может ли декораторы быть прямым ребенком компонента?

Question

Глядя на странице шаблона Decorator на википедии (http://en.wikipedia.org/wiki/Decorator_pattern), макет выглядит примерно так:

• компонентов интерфейса реализации
• Компонент
• интерфейс декоратор, который реализует интерфейс компонентов
• декоратора (s), которые реализуют интерфейс декоратора

Может ли декораторы вместо этого непосредственно реализовать компонент интерфейс (и пропустить интерфейс декодера)?

Answer 1

Основное преимущество, которое вы получаете с помощью шаблона Decorator, заключается в том, что для клиентского кода он прозрачен. Они не должны знать о декораторе, они могут рассматривать его как обычную старую конкретную реализацию базового интерфейса:

ThingDoer thingDoer = new ThingDoerDecorator(new AwesomeThingDoer()); 
ThingDoer otherThingDoer = new AwesomeThingDoer(); 

thingDoer.doThing(); 
otherThingDoer.doThing(); 

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

Однако иногда имеет смысл иметь базовый декоратор, реализующий.

abstract class BaseThingDoerDecorator implements ThingDoer { 
    private ThingDoer thingDoer; 

    protected BaseDecorator(ThingDoer thingDoer) { 
     this.thingDoer = thingDoer; 
    } 

    @Override 
    public void doThing() { 
     thingDoer.doThing(); 
    } 
} 

Теперь становится практичным, чтобы сделать такие вещи, как это:

ThingDoer thingDoer = new BaseThingDoerDecorator(new AwesomeThingDoer()) { 
    @Override 
    public void doThing() { 
     System.out.println("This is an anonymous decorator"); 
     super.doThing(); 
    } 
}; 

Или, может быть, вы хотите, чтобы все ваши декораторы быть защищены от исключений в базовом компоненте:

abstract class BaseThingDoerDecorator implements ThingDoer { 
    // Same as above... 
    // ... 
    @Override 
    public void doThing() { 
     try { 
      thingDoer.doThing(); 
     } catch (Exception e) { 
      log(e); 
     } 
    } 
} 

Answer 2

Вот UML диаграмма со страницы википедии вы цитируемой:

На этой диаграмме, декоратор не интерфейс, но абстрактный класс. Компонент также является не интерфейсом на этой диаграмме (так как ConcreteComponent и Декораторы, наследующие от него, не имеют пунктирных линий со стрелки на диаграмме). Я знаю, что это деталь, но UML определен по какой-то причине.

Таким образом, любой ConcreteDecorator может наследовать непосредственно из Component (или реализовать его интерфейс, если ваш проект использует интерфейс) без использования абстрактного класса Decorator . Тем не менее, all ConcreteDecorators необходимо объединить компонент, поэтому абстрактный класс может быть полезен, чтобы избежать дублирования кода, если у вас есть несколько ConcreteDecorator.