设计模式–装饰器模式

装饰器模式，最常用的设计模式之一

这是一个新的工程。我们有一个类叫做 HistorySet，它带有一个泛型参数，表示集合中的元素类型。这个集合既像普通的 Set 一样支持增删改查，又能在元素被 remove 掉的时候保留历史记录。

我们先思考如何实现这个功能。既然它是一个 Set，我们可以直接实现 Set<E> 接口，然后实现其中的所有方法。不过我们重点关注的是 remove 方法——如何在删除元素的同时，记录下被删除的元素？

我们可以用一个 List<E> 来保存这些被删除的元素，比如命名为 removedList。当一个元素成功从集合中移除后，我们就把这个元素添加到 removedList 中。

public class HistorySet<E> implements Set<E> {

    List<E> removeList = new ArrayList<>();

    @Override
    public int size() {
        return 0;
    }

    @Override
    public boolean isEmpty() {
        return false;
    }

    @Override
    public boolean contains(Object o) {
        return false;
    }

    @Override
    public Iterator<E> iterator() {
        return null;
    }

    @Override
    public Object[] toArray() {
        return null;
    }
    @Override
    public boolean remove(Object e){
        return false;
    }
    @Override 
    public boolean containsAll(Collecction<?> c){
        return false;
    }
    @Override
    public void clear(){
    }
    @Override
    public String toString(){
        return hashSet.toString() +" remove list: " + removeList;
    }
}

现在的问题是：如何实现 Set 接口的其他方法？如果我们有一个已经实现了 Set 接口的类（比如 HashSet），能不能把所有功能都委托给它来完成，而我们只需要在关键的地方（如 remove）做增强处理？

答案是可以的。我们在 HistorySet 内部持有一个 Set<E> 的实例，比如
private Set hashSet =new HashSet<>();

这样，size() 就直接返回 hashSet.size()，isEmpty() 返回 hashSet.isEmpty()，add() 直接调用 hashSet.add()，其他方法也都交给这个内部的 HashSet 去完成。

唯独 remove 方法我们需要特殊处理。因为 remove 有返回值：如果返回 true，说明元素确实被移除了；如果返回 false，说明元素原本就不在集合中，无需处理。因此，我们先调用 hashSet.remove(o)，判断返回值：

@Override
public boolean remove(Object o) {
    if(hashSet.remove(o)){
        removeList.add((E)o);
        return true;
    }
    return false;
}

注意这里有个泛型问题：remove 参数是 Object 类型，而我们要存入 List<E>，所以需要强制类型转换。在实际使用中应确保类型安全。

接下来我们写一个测试的 main 函数。创建一个 HistorySet<Integer> 实例，可以用 Set<Integer> 多态引用：

public class Main {
    public static void main(String[] args) {
        Set<String> set = new HistorySet<>();
        set.add("1");
        set.add("2");
        set.add("3");
        set.add("4");
        set.remove("4");
        set.remove("4");
        set.remove("5");
        set.remove("1");
        System.out.println(set);
    }
}

然后我们打印这个 set。但我们还没写 toString() 方法，已经补上

 [2,3] remove list : [4,1]

运行后输出显示：当前集合中有 2 和 3，被删除的元素是 4 和 1，而 5 因为从未存在过，所以没有被记录。

我们再回头看这个 HistorySet 类。我们实现了 Set 接口，但我们自己并没有真正实现任何 Set 的逻辑，而是把所有操作都交给了内部的 HashSet。这说明我们其实并不依赖 HashSet，只要是 Set 的实现都可以。

那如果我们希望底层是有序的 Set（比如 TreeSet），怎么办？我们可以让用户在构造时传入一个 Set 实例，而不是固定使用 HashSet。private Set hashSet =new TreeSet<>();

于是我们修改构造函数：

public HistorySet(Set<E> delegate) {  
    this.delegate = delegate;  
}  

这个 delegate 就是被代理的对象。我们在创建 HistorySet 时传入一个 HashSet 或 TreeSet 都可以：

public HistorySet(Set<E> hashSet) {
    this.delegate = hashSet;
}

List<E> removeList = new ArrayList<>();
private final Set<E> delegate;

这样，HistorySet 的职责就非常清晰：它只是一个“包装器”，只增强 remove 功能，其余所有行为都由代理对象完成。

这就是装饰器模式的核心思想：通过包装一个对象，在不改变其原有功能的前提下，增加新的行为或功能。

更进一步，既然 HistorySet 本身也是一个 Set，那我们能不能把它再包装一次？比如：装饰的historyset作为set进一步放到historyset中，记录分别remove的系统；

public class Main {
    public static void main(String[] args) {
        Set<String> historySet = new HistorySet<>(new HashSet<>());
        Set<String> set = new HistorySet<>(historySet);
        set.add("1");
        set.add("2");
        set.add("3");
        set.add("4");
        set.remove("4");
        set.remove("4");
        set.remove("5");
        set.remove("1");
        System.out.println(set);
    }
}

这时，doubleHistorySet 内部嵌套了两个 HistorySet。每次成功删除一个元素，两个包装器都会记录一次。运行测试后可以看到，两个 removedList 都记录了相同的删除操作。

【2,3】remove list :[4,1] remove list :[4,1]

这说明装饰器可以层层叠加，形成“装饰链”。

我们来看一个 JDK 中的经典例子：Collections.synchronizedCollection(Collection<T> c)。它接收一个 Collection，返回一个线程安全的包装版本。

Collection