源码中的设计模式略读

找出两个项目中的设计模式，更加理解设计模式在框架中的应用。

项目1：https://github.com/dangdangdotcom/config-toolkit

业务场景：当zk中的配置变化的时候，实时通知业务程序。

监听器模式：

监听者应用1：

CuratorListener：监听者接口，监听zk变化

CuratorFramework：被监听者

ConfigNodeEventListener：监听者实现  ， ConfigNodeEventListener.eventReceived：监听者动作 ， ZookeeperConfigGroup被监听者更新的数据对象 （详见eventReceived方法）

监听者应用2：

ISubject 被监听者接口

GeneralConfigGroup，ZookeeperConfigGroup 被监听者实现。两种方式通知监听者：一分钟定时通知下监听者；由例子1中的 Curator通知 ZookeeperConfigGroup，转而触发：reloadKey->super.put->notify 

IObserver 监听者接口

RefreshableBox 监听者实现

桥接模式：

项目：https://github.com/sumory/gru 

业务场景：zookeeper数据变化的时候，实时改变本地节点数据。

public abstract class ZkClientWatcher implements Watcher{//Watcher是zookeeper监听器接口。

.....zooKeeper = new ZooKeeper(zkHost, sessionTimeout, this);//注册监听器
public void process(WatchedEvent event) {//该方法是zookeeper的监听器执行具体动作接口
....processNodeCreated...//调用了一个抽象方法,而抽象方法在子类中实现，客户端new 的是子类。
}
protected abstract void processNodeCreated(String path);

}

public class TicketZkClientWatcher extends ZkClientWatcher{

private Shard<Node> shard;

@Override
protected void processNodeCreated(String path) {//具体实现

....//改变本地节点 shard

}
}

其实看的出来，ZkClientWatcher 和 TicketZkClientWatcher 两个类进行了功能解耦。一个负责从zookeeper拿数据，一个负责改变本地节点。

ZkClientWatcher 这个类作为“桥”，把 TicketZkClientWatcher（具体实现） 和 Watcher(抽象行为) 连接了起来。

跟适配器模式很像，都“连接”了两个对象。都属于结构模式的一种，但又有差异：

适配器模式：

客户端使用A接口（Target）。

需要调用B接口（Adaptee）。

可以由C类实现A接口，再间接调用B接口来完成。

最后总结一下两天的心得：设计模式需要结合具体的实例代码才能明白其用意，需要慢慢悟，才能悟出其中道理。