一步一步将自己的代码转换为观察者模式

     之前有发表博文，简单的讲解一下观察者模式的大概内容(http://www.cnblogs.com/wenjiang/archive/2013/05/07/3065040.html)，主要是利用java对观察者模式的内置支持来实现观察者模式，现在想要换个思路，自定义观察者模式。

     这次使用Eclipse的单元测试框架，前面那个例子就不适合了，所以特意挑一个有关时钟报时的例子，方便测试。

     敏捷开发的原则就是测试先于代码，这里就采用这个原则，先从测试代码开始：

public class ClockTest extends TestCase {
    private TimeScreen screen;
    private TimeSource source;
     
    public ClockTest(String name) {
       super(name);
   }

    public void testTimeChange() {
       TimeSource source = new TimeSource();
       TimeScreen screen = new TimeScreen();
       Clock clock = new Clock(source, screen);
       source.setTime(3, 4, 5);
       assertEquals(3, screen.getHours());
       assertEquals(4, screen,getMinutes());
       assertEquals(5,screen.getSeconds());
   }
}

      该测试主要测试：当时钟时间改变时，屏幕能否跟着改变。
      因为时钟可能是电子时钟或者其他时钟，所以，我们定义一个时间来源的抽象:Source:

public interface Source{
    public void setSource(Clock clock);
}

      同样屏幕也要有一个抽象:

public interface Screen{
    public void setTime(itn hours, int minutes, int seconds);
}

      接着是Clock的代码:

public class Clock{
     priate Screen screen;
     
     public Clock(Source source, Screen screen){
          source.setClock(this);
          this.screen = screen;
     }

     public void update(int hours, int minutes, int seconds){
           screen.setTime(hours, minutes, seconds);
     }
}
          

      Clock通知屏幕更新时间，所以它必须拥有Screen的运用，又因为它是从Source获取时间，所以它必须将自己传给Source，也就是说，它是Screen和Source之间的邮差。

      我们来实现具体的Screen和Source:

public class TimeSource implements Source{
      private Clock clock;
      
      public void setTime(int hours, int minutes, int seconds){
            clock.update(hours, minutes, seconds);
      }

      public void setClock(Clock clock){
            this.clock = clock;
      }
}

public class TimeScreen implements Screen{
     private int hours;
     private int minutes;
     private int seconds;

     public int getHours(){
           return this.hours;
     }

     public int getMinutes(){
          return this.minutes;
     }

     public int getSeconds(){
          return this.seconds;
     }
     
     public void setTime(int hours, int minutes, int seconds){
          this.hours = hours;
          this.minutes = minutes;
          this.seconds = seconds;
    }
}

       UML图如：

      

      上面的代码能够通过测试，但并不是一个好方案，最主要的问题就是TimeSource持有Clock的引用。Clock确实是Source和Screen的邮差，但我们并不依赖于具体的邮差帮我们传送数据，邮差本身也可以是一个抽象:

public interface TimeObserver{
     public void update(int hours, int minutes, int seconds);
}

      为了贴近今天的主题，特意将这个抽象命名为TimeObserver，因为它就是一个观察者，观察数据什么时候改变，然后通知相应的屏幕。

     然后就是实现这个抽象：

public class Clock implements TimeObserver{
     private Screen screen;

     public Clock(Source source, Screen screen){
          source.setObserver(this);
          this.screen = screen;
     }

     public void update(int hours, int minutes, int seconds){
           screen.setTime(hours, minutes, seconds);
     }
}

      接着就是将原本引用Clock的地方都改为TimeObserver就行，像是下面这样:

public interface Source{
      public void setObserver(TimeObserver observer);
}

      加入这样的抽象的好处非常明显，就是消除我们之前的依赖，也就是通过提供间接层的方式消除依赖的做法，这也是接口的作用。

     

      通过查看代码，我们发现TimeObserver的update()其实就是调用Screen的setTime()，这是因为它必须通知Screen修改显示的时间,那么我们是否可以直接将Screen传递给Source的方法，而不是像之前那样需要TimeObserver？显然我们的测试代码需要进一步修改,修改的地方只有一处:

source.setObserver(screen);

       然后是我们的Source:

public class TimeScreen implements TimeObserver{
      private int hours;
      private int minutes;
      private int seconds;

      public int getHours(){
           return this.hours;
      }

      public int getMinutes(){
           return this.minutes;
      }

      public int getSeconds(){
           return this.seconds;
      }

      public void update(int hours, int minutes, int seconds){
           this.hours = hours;
           this.minutes = minutes;
           this.seconds = seconds;
      }
}

      

      为什么我们一开始会有一个Clock呢？因为我们需要一个邮差，但为什么不让我们的Source直接通知Screen呢？我们经常会犯这样的错误，尤其是在使用接口的时候，认为凡事有个间接层都是好的，都是动态的，其实不然，接口的确是个好东西，但是，该让谁实现这个接口就是一个问题。我们很容易像是上面一样，引入了一个具体类型Clock，而且代码的运行也没有错，它依然能够工作得很好，我们还可以和别人炫耀：看看我的邮差工作得多努力！
     如何设计好接口，是面向对象编程中一个很重要的努力方向。

     我的个人经验，当然，这经验是微不足道的(面向对象编程经验只有一年OTZ)，如果两个类型之间需要进行通信，应该是让它们的抽象之间进行通信，也就是它们各自实现的接口，这样就能消除具体类型的耦合，而且这种通信的方式是以传参的方式进行。这样，我们的对象层次上既保证一定的解耦，又能保证逻辑上的耦合关系的完整。

     之前的测试实在是太简单了，只是单独测试一个Screen，现实生活中的情况是非常复杂的，我们很可能需要多个屏幕，而且它们是不同材质，不同地方，这需要增加一个测试:

public void testMultipleScreens(){
      TimeSource source = new TimeSource();
      TimeScreen screen = new TimeScreen();
      source.registerObserver(screen);
      
      TimeScreen screen2 = new TimeScreen();
      source.registerObserver(screen2);

      source.setTime(3, 4, 5);
      assertScreenEquals(screen, 3, 4, 5);
      assertScreenEquals(screen2, 3, 4, 5);
}   

private void assertScreenEquals(TimeSource source, int hours, int minutes, int seconds){
      assertEquals(hours, screen.getHours());
      assertEquals(minutes, screen.getMinutes());
      assertEquals(seconds, screen.getSeconds());
}

      我们在Source里增加了一个方法:registerObserver()，正如其名，就是将相关的Screen注册进Source需要通知的名单中，新的Source如：

public interface Source{
     public void registerObserver(TimeObserver observer);
}

      接着我们的TimeSource如：

public class TimeSource implements Source{
     private List<TimeObserver> observers = new ArrayList<TimeObserver>();
    
    public void registerObserver(TimeObserver observer){
          list.add(observer);
    }

    public void setTime(int hours, int minutes, int seconds){
          for(TimeObserver observer : observers){
               observer.update(hours, minutes, seconds);
          }
    }
}    

      我们用ArrayList来作为存储需要通知的Screen的名单，然后在时间更新的时候，逐个通知它们更新自己的时间。
      但问题也来了，任何一个Source的实现类都必须实现注册和更新的代码，哪怕它们都是一样的。这样代码的重复性太高了，我们得想办法解决这个问题。

      将Source从接口变为类型就可以解决了：

public class Source{
     private List<TimeObserver> observers = new ArrayList<TimeObserver>();
     
     protected void notify(int hours, int minutes, int seconds){
          for(TimeObserver observer : observers){
               observer.update(hours, minutes, seconds);
          }
     }
     
    public void registerObserver(TimeObserver observer){
          observers.add(observer);
    }
}

       然后我们的TimeSource只需要这样:

public class TimeSource extends Source{
      public void setTime(int hours, int minutes, int seconds){
            notify(hours, minutes, seconds);
      }
}

      我们的派生类型的确是不需要重新写注册和更新的代码，只要调用基类的相关方法就行。

     

      从上面我们可以知道，接口可以为我们提供间接层，减少具体类型的依赖，使得我们的代码更具动态，但是，它会使我们面临代码重复性较高的危险，更可怕的是，它会让我们陷入这样的怪论:"只要能呱呱叫，就是鸭子"。这是面向对象编程的一个经典现象，因为所有实现类都要实现接口规定的方法，而且我们不能阻止非目标类型对该接口的实现。

     使用继承可以解决上面的怪论:"只有鸭子才能呱呱叫"。这是继承的本质，它规定的是一种类型，而不是一组行为协定。当然，接口也有自己的对策：将行为协议划分得更细，最好就是一组相关的行为放到一个接口里。前面之所以会出现这样的怪论，是因为程序员可能会这样设计接口:

public interface Duck{
     public void fly();
     public void shout();
} 

     这样的接口就会让人产生误解，正确的接口应该是这样的：

public interface FlyAble{
     public void fly();
}

public interface ShoutAble{
     public void shout();
}

     接口的命名应该是动词，而不是名词，因为它规定的是一组行为协议。

     但继承也存在自己的问题："不是所有的鸭子都会呱呱叫"，有些鸭子可能不会叫，但是它们是有方法可以呱呱叫的，这就会出现错误。

     所以，使用继承解决问题的时候，我们必须明确一点：派生类能从基类中继承的职责到底是什么？

     在这里，很明确的就是，我们的Source根本就没有必要理会注册和更新的行为，它本来应该只知道时间而已。于是，我们需要将这部分的职责从Source中移除。

     使用委托是一个不错的选择:

public class TimeNotify{
     private List<TimeObserver> observers = new ArrayList<TimeObserver>();
    
    public void registerObserver(TimeObserver observer){
          list.add(observer);
    }

    public void setTime(int hours, int minutes, int seconds){
          for(TimeObserver observer : observers){
               observer.update(hours, minutes, seconds);
          }
    }
}    

public class TimeSource implements Source{
     private TimeNotify notify = new TimeNotify();

     public void registerObserver(TimeObserver observer){
          notify.registerObserver(observer);
     }

     public void setTime(int hours, int minutes, int seconds){
          notify.notify(hours, minutes, seconds);
     }
}

public class TimeNotify{
     private List<TimeObserver> observers = new ArrayList<TimeObserver>();
    
    public void registerObserver(TimeObserver observer){
          list.add(observer);
    }

    public void setTime(int hours, int minutes, int seconds){
          for(TimeObserver observer : observers){
               observer.update(hours, minutes, seconds);
          }
    }
}    

public class TimeSource implements Source{
     private TimeNotify notify = new TimeNotify();

     public void registerObserver(TimeObserver observer){
          notify.registerObserver(observer);
     }

     public void setTime(int hours, int minutes, int seconds){
          notify.notify(hours, minutes, seconds);
     }
}

public class TimeNotify{
     private List<TimeObserver> observers = new ArrayList<TimeObserver>();
    
    public void registerObserver(TimeObserver observer){
          list.add(observer);
    }

    public void setTime(int hours, int minutes, int seconds){
          for(TimeObserver observer : observers){
               observer.update(hours, minutes, seconds);
          }
    }
}    

public class TimeSource implements Source{
     private TimeNotify notify = new TimeNotify();

     public void registerObserver(TimeObserver observer){
          notify.registerObserver(observer);
     }

     public void setTime(int hours, int minutes, int seconds){
          notify.notify(hours, minutes, seconds);
     }
}

       使用委托是增加了一个间接层，专门用于负责注册和更新的具体实现，而我们的Source只要调用它的相应方法就行。

      
       哦，间接层怎么又来了！明明开头我们消除了一个邮差，现在又来了个新的邮差！！此邮差非彼邮差。之前的邮差是因为我们的Source的具体类型要持有一个邮差的引用才能通知Screen的具体类型，但是事实就是Source的具体类型应该可以直接通知Screen的具体类型，这是职责的分离。但这里我们是职责过分集中在一个类型中，所以需要通过间接层将职责分离出去。

      我们知道，这样的解释实在是太模糊了！同样是邮差，为什么一个邮差要被赶走，另一个邮差却要被雇佣，而且评价甚高！！这不公平！！！仔细想想它们的工作就知道了，之前的邮差它负责的工作是更新数据，而且还是命令Screen更新！！这就是冗余，所以它才会被赶走，但是现在这个邮差却负责了新的工作：通知Screen更新数据和注册新的Screen，Source的工作仅仅是命令它做事而已。这样辛苦工作的邮差怎么可能被炒呢！！

      现在的我们已经将整个观察者实现出来了，只要将Source改为TimeSubject就行，因为在观察者模式中，被观察的就是Subject，而java中习惯的命名方式是TimeObservable。我们这里采用的是"推模型"，也就是通过把数据传给notify和update方法从而把数据从Subject推给观察者Observer，而另一种方式"拉模型"是Observer在收到更新消息后，查询Subject得到。该使用哪种方式，就在于Observer是否知道是哪个Subject发生变化(Subject可以是多个)，如果确定的话，可以使用"拉模型"，否则使用"推模型"比较方便。

      下面就是观察者模式的大概UML图：

     

      观察者模式是一个非常好用的设计模式，它应用的范围非常广泛，解决了很多设计问题，而且存在各种变形，但万变不离其宗，只要我们谨记模式的意图，就能在我们毫无头绪的时候指点迷津，尤其是在一开始设计类的时候，如果画一下UML图，就会发现我们可以用观察者模式来解决这个问题。