源码中的设计模式略读

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


项目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;   @Overrideprotected void processNodeCreated(String path) {//具体实现    ....//改变本地节点 shard}}

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

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

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

适配器模式：

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

需要调用B接口（Adaptee）。

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

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