design-patterns - 无法理解装饰器模式的主要缺点

Question

我正在学习装饰器模式。这是一个非常强大的模式，而且非常有用。该模式的目标很简单，在运行时向对象添加(扩展)行为，而无需通过组合和委托(delegate)重新编译源代码，因此为扩展行为提供了子类化的替代方案。但是，我阅读了这种模式的主要缺点之一，并不太理解它。声明如下:

"People sometimes take a piece of client code that relies on specific types and introduce decorators without thinking through everything. Now, one great thing about me is that you can usually insert decorators transparently and the client never has to know it's dealing with a decorator. But like I said, some code is dependent on specific types and when you start introducing decorators, boom! Bad things happen."

取自“Head first design patterns”

作者所说的“依赖特定类型”是什么意思。如果可能，请提供真实世界和简单示例

Answer 1

有时您的代码会像在 java 中那样进行类型检查

a instanceof B

甚至

a.getClass == B.class

这种检查中断

如果 a 不再是 B 而是包裹在 A 周围的装饰器 D

举个具体的例子:

I b = new B; // I is an interface implemented by B
b = D(b); // the decorator D implements I as well
doSomething(b);

doSomething 定义如下:

doSomething(I i){
    if i instanceof B
        doThis();
    else
        doThat();
}

通过引入装饰器 D，行为从 doThis() 变为 doThat()

在现实世界中经常发生这种情况的例子是 Hibernate。在某些情况下，它会在提供额外 Hibernate 特定行为的实体周围生成代理。如果使用这些实体的代码进行上述检查，它将根据实体的创建方式而中断。实际上 的实例可能有效，但 getClass() 变体肯定会失败。