装饰器 （Decorator）

定义：动态地将一个对象添加一些额外的职责，就添加功能来说，装饰模式比生成子类更为灵活。

场景：在不想增加很多子类的情况下扩展类；动态增加功能，动态撤销。

类型：结构型

复合优先于继承，这是EJ中提到装饰器时的Tip标题，它很好的表达了装饰器出现的原因。
继承是实现代码重用的强大工具，但并非总是最佳工具，其中一个原因是：继承破坏了封装性。

换句话说，子类依赖于其超类中特定功能的实现细节。超类的实现有可能会随着发行版本的不同而有所变化，如果真的发生了变化，子类可能会遭到破坏，即使它的代码完全没有改变。

这里所讲的变化可以是以下任意一种：

• 父类的方法在类内互相调用，这种 自用性 (self-use) 是实现细节，开发者可能会认为方法之间是独立的，如果覆盖某个被依赖的方法，依赖方也会受影响，并且在未来的发行版本中这种依赖关系是变化的、不稳定的。
• 子类对所有方法加入了一种先决条件，例如验参，父类如果在后续的发行版本添加新的方法，就会成为“漏网之鱼”，造成安全问题。
• 在新的发行版本中父类编写了一个新方法，恰好与某个子类的新增方法签名冲突，造成编译失败。
• ···

总而言之，倘若不是专门为了继承而设计并且具有很好的文档说明的类，在多人协作，特别是跨越包边界时（泛指不再对子类编写、迭代的规范有强约束力）使用继承非常危险，会让系统变得更加脆弱。
所幸有一种方法可以避免继承的种种问题，即 复合-转发。

不扩展现有的类，而是在新的类中增加私有域，引用现有类的一个实例，这种设计被称为 “复合”（composition） ；
新类中每个实例方法都可以调用被包含的现有类实例中对应的方法，并返回他的结果，这被称为 “转发”（forwarding） 。

我们还是来看集合框架中的一个典型例子（今天跟集合框架杠上了...

public class Collections {

    public static <K, V> Map<K, V> checkedMap(Map<K, V> m,
                                              Class<K> keyType,
                                              Class<V> valueType) {
        return new CheckedMap<>(m, keyType, valueType);
    }
    
    private static class CheckedMap<K,V> implements Map<K,V>, Serializable {

        private final Map<K, V> m;
        final Class<K> keyType;
        final Class<V> valueType;
        
        CheckedMap(Map<K, V> m, Class<K> keyType, Class<V> valueType) {
            this.m = Objects.requireNonNull(m);
            this.keyType = Objects.requireNonNull(keyType);
            this.valueType = Objects.requireNonNull(valueType);
        }
        
        public int size()                      { return m.size(); }
        public boolean isEmpty()               { return m.isEmpty(); }
        public boolean containsKey(Object key) { return m.containsKey(key); }
        public boolean containsValue(Object v) { return m.containsValue(v); }
        public V get(Object key)               { return m.get(key); }
        public V remove(Object key)            { return m.remove(key); }
        public void clear()                    { m.clear(); }
        public Set<K> keySet()                 { return m.keySet(); }
        public Collection<V> values()          { return m.values(); }
        public boolean equals(Object o)        { return o == this || m.equals(o); }
        public int hashCode()                  { return m.hashCode(); }
        public String toString()               { return m.toString(); }

        public V put(K key, V value) {
            typeCheck(key, value);
            return m.put(key, value);
        }
        
        private void typeCheck(Object key, Object value) {
            if (key != null && !keyType.isInstance(key))
                throw new ClassCastException(badKeyMsg(key));

            if (value != null && !valueType.isInstance(value))
                throw new ClassCastException(badValueMsg(value));
        }
        
        //省略剩余方法
    }    
}

这回介绍的是Collections::checkedMap，这个静态工厂使用不多，其作用是为map实例提供键值对类型检查。现如今Map接口已是一个泛型，但在JAVA SE5之前编写的各类map实现，是没有类型检查的能力的。当我们不能去改造老的类库时，只需一句简单的调用：

Map<Integer, String> typeSafeMap = Collections.checkedMap(new OldMap(), Integer.class, String.class);

即可为老类库赋予和泛型一样的类型检查能力，我们来细品代码。

静态工厂中返回了 CheckedMap 的新实例， CheckedMap 是实现了 Map 接口的内部类，定义了私有变量 Map 用于接收map实例；两个 Class 字段，分别保存键值的类型。对于大多数方法， CheckedMap 直接将调用 转发 至原map上，但在 put 这样的插入操作中，在转发前调用了私有的 typeCheck 方法，执行类型检查。

避开继承，使用装饰器，我们同样能为现有类追加新的功能。同时装饰器本身还可以再次被装饰，这使得装饰器是动态的、可拆卸的。
例如对现有类同时赋予 类型安全、线程安全 的特性。

        Map<Integer, String> safeMap = Collections.synchronizedMap(
                Collections.checkedMap(new OldMap(), Integer.class, String.class)
        );

装饰器本身也有编写成本，因为需要将所有方法进行转发，但往往需要装饰的方法较少。 Guava 做了这方面考虑，在collect包下为所有集合接口编写了转发类，类名格式：ForwardingXXX。开发者只需继承这些转发类，重写需要装饰的方法即可。

参考：

[1] Effective Java - 机械工业出版社 - Joshua Bloch (2017/11)

[2] 《大话设计模式》 - 清华大学出版社 - 陈杰 (2007/12)