Oop 装饰设计模式问题？

在《头优先设计模式》（Head first design patterns）一书的装饰者一章中，它讨论了装饰者处理具体类型和导致问题的问题。我复制了本章中的一些问答：

问：我有点担心代码可能会测试一个特定的具体组件，比如HouseBlend，然后做一些事情，比如打折。一旦我用装饰师把房子包装好，这就不管用了

A:完全正确。如果您的代码依赖于具体组件的类型，则装饰程序将破坏该代码。只要您只针对抽象组件类型编写代码，装饰器的使用对您的代码将保持透明。然而，一旦开始针对具体组件编写代码，您就需要重新考虑应用程序设计和装饰器的使用

有人能举个简单的例子说明“客户机”代码是针对具体类型还是抽象类型编写的吗？而前者又是如何给装饰师带来麻烦的呢

书中decorator的测试代码示例如下：

public class StarbuzzCoffee {
    public static void main(String args[]) {
        Beverage beverage2 = new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription()
            + “ $” + beverage2.cost());
        ...
    }
}

这个测试代码（也是客户机代码）是针对抽象类型编写的吗

---

谢谢，

例如，他们正在讨论检查beverage2类型的代码

if (beverage2 instanceof DarkRoast) {
    <do_something>
}

if（暗室的beverage2实例）{
}

一旦你用摩卡咖啡或鞭子装饰贝弗拉格2，它就不再是暗室了

编辑：我还应该提到，通常使用

instanceof

表示设计不好，没有充分利用OO，也就是说它在某些情况下是有用的

只要您只针对抽象组件类型编写代码，装饰器的使用对您的代码将保持透明

对。应该是这样的

您不应该装饰特定于具体装饰器实现的新功能。一旦你这样做了，装饰图案的目的就失去了

Decorator模式运行良好，因为抽象Decorator包含接口本身（使用组合）。它有助于减少不同口味的不同组合的数量

我已经实现了类似用例的模式。请查看此文档链接

您将得到18的输出，即

茶（10）+柠檬（5）+糖（3）

：

对于上面的示例，您需要对抽象

Decorator

进行一些更改，如文档链接中所述。由于

Decorator

抽象类中的

饮料

的成分，可以轻松添加多种口味

永远不要添加基于具体装饰器的业务逻辑。一旦在代码中加入了混凝土装饰器的智能，就失去了独立添加动态职责的灵活性

 Beverage beverage = new SugarDecorator(new LemonDecorator(new Tea("Assam Tea")));
 beverage.buildBeverage();

Cost of:Assam Tea+Lemon +Sugar :18