设计模式 – 77博园

装载请标明出处：http://77blogs.com/?p=279

观察者模式

说白了，就是一个对发生改变，所有依赖于它的对象也发生改变，这是一对多的关系。

比如对象A，对象B，对象C。B与C依赖于A，那么A发生改变，B与C也将发生改变。此时A是被观察者，B与C是观察者。

观察者模式又被称作发布/订阅模式，主要是为了让观察者与被观察者之间进行解耦。

UML图：

角色说明：

Subject（抽象主题）：被观察者的一个抽象类，它会把所有观察者的引用保存在一个集合里。抽象主题提供一个接口，可以增加和删除观察者对象。

ConcreteSubject（具体主题）：具体的被观察者。当具体被观察者的状态发生改变的时候，会给每一个注册过的观察者发送通知。

Observer（抽象观察者）：所有具体观察者的一个抽象类，为所有的具体观察者定义了一个接口：得到主题的通知时候更新自己。

ConcrereObserver（具体观察者）：抽象观察者的具体实现。

我们看一下具体的例子：

上课铃声响起时候，老师与学生们的不同反应。

1、定义一个抽象主题：

该抽象主题定义了一些通用的方法，即具体主题里面需要实现的。

//抽象被观察者
public interface Observable {
    //添加观察者
    void addObserver(Observer observer);

    //移除观察者
    void deleteObserver(Observer observer);

    //通知观察者
    void notifyObserver(String msg);
}

//抽象被观察者

public interface Observable {

//添加观察者

void addObserver(Observer observer);

//移除观察者

void deleteObserver(Observer observer);

//通知观察者

void notifyObserver(String msg);

}

2、创建一个具体主题（上课铃声）：

public class AlarmClock implements Observable {
    //保存观察者对象
    List list = new ArrayList<>();

    @Override
    public void addObserver(Observer observer) {
        list.add(observer);
    }

    @Override
    public void deleteObserver(Observer observer) {
        list.remove(observer);
    }

    /**
     * 通知观察者
     * @param msg
     */
    @Override
    public void notifyObserver(String msg) {
        for (Observer observer : list) {
            observer.action(msg);
        }
    }
}

public class AlarmClock implements Observable {

//保存观察者对象

List list = new ArrayList<>();

@Override

public void addObserver(Observer observer) {

list.add(observer);

}

@Override

public void deleteObserver(Observer observer) {

list.remove(observer);

}

/**

* 通知观察者

* @param msg

@Override

public void notifyObserver(String msg) {

for (Observer observer : list) {

observer.action(msg);

}

3、创建抽象观察者：

定义了所有具体观察者需要实现的方法，听到铃声后的行为

//抽象观察者
public interface Observer {
    void action(String msg);
}

//抽象观察者

public interface Observer {

void action(String msg);

}

4、创建具体观察者：

public class Students implements Observer {

    String name;

    public Students(String name) {
        this.name = name;
    }

    @Override
    public void action(String msg) {
        System.out.println(msg + name + "开始听课");
    }
}
public class Teacher implements Observer {
    @Override
    public void action(String msg) {
        System.out.print(msg + "老师开始讲课");
    }
}

public class Students implements Observer {

String name;

public Students(String name) {

this.name = name;

}

@Override

public void action(String msg) {

System.out.println(msg + name + "开始听课");

}

public class Teacher implements Observer {

@Override

public void action(String msg) {

System.out.print(msg + "老师开始讲课");

}

6、实现：

Observable alarmClock = new AlarmClock();

Observer student1 = new Students("小屁孩");
Observer student2 = new Students("大屁孩");
Observer teacher = new Teacher();

//注册观察者
alarmClock.addObserver(student1);
alarmClock.addObserver(student2);
alarmClock.addObserver(teacher);

//被观察者通知已经注册的观察者
alarmClock.notifyObserver("上课铃声已经响了");

Observable alarmClock = new AlarmClock();

Observer student1 = new Students("小屁孩");

Observer student2 = new Students("大屁孩");

Observer teacher = new Teacher();

//注册观察者

alarmClock.addObserver(student1);

alarmClock.addObserver(student2);

alarmClock.addObserver(teacher);

//被观察者通知已经注册的观察者

alarmClock.notifyObserver("上课铃声已经响了");

7、结果：

到这里我们便实现了观察者模式。

应用场景

当一个对象的改变需要通知其它对象改变时，而且它不知道具体有多少个对象有待改变时。
当一个对象必须通知其它对象，而它又不能假定其它对象是谁
跨系统的消息交换场景，如消息队列、事件总线的处理机制。

优点

解除观察者与主题之间的耦合。让耦合的双方都依赖于抽象，而不是依赖具体。从而使得各自的变化都不会影响另一边的变化。
易于扩展，对同一主题新增观察者时无需修改原有代码。

缺点

依赖关系并未完全解除，抽象主题仍然依赖抽象观察者。
使用观察者模式时需要考虑一下开发效率和运行效率的问题，程序中包括一个被观察者、多个观察者，开发、调试等内容会比较复杂，而且在Java中消息的通知一般是顺序执行，那么一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般会采用异步实现。
可能会引起多余的数据通知。

JDK内部也内置了Observable（抽象被观察者），Observer（抽象观察者）这两个类，我们也可以直接拿来用，具体可以去看看源码。

Android中有很多地方也用到了观察者模式：

点击事件

listView的刷新

广播等等

单例模式是设计模式中比较常见简单的一种，典型双重检测写法如下：

public class SingletonClass { 

  private volatile static SingletonClass instance = null; 

  public static SingletonClass getInstance() { 
    if (instance == null) { 
      synchronized (SingletonClass.class) { 
        if(instance == null) { 
          instance = new SingletonClass(); 
        } 
      } 
    } 
    return instance; 
  } 
  private SingletonClass() { 
  } 
}

public class SingletonClass {

private volatile static SingletonClass instance = null;

public static SingletonClass getInstance() {

if (instance == null) {

synchronized (SingletonClass.class) {

if(instance == null) {

instance = new SingletonClass();

}

return instance;

}

private SingletonClass() {

}

接下来对该写法进行分析，为何这样写？

一、为何要同步：

多线程情况下，若是A线程调用getInstance，发现instance为null，那么它会开始创建实例，如果此时CPU发生时间片切换，线程B开始执行，调用getInstance，发现instance也null（因为A并没有创建对象），然后B创建对象，然后切换到A，A因为已经检测过了，不会再检测了，A也会去创建对象，两个对象，单例失败。因此要同步。

二、同步为何不用 public synchronized static SingletonClass getInstance()，也就是说为何不同步这个方法，而要同步下面的语句：

因为synchronized修饰的同步块可是要比一般的代码段慢上几倍，如果经常调用getInstance,那么性能问题就得考虑了。

三、最外层为何要有if (instance == null)判断：

因为我们在分析二中，发现依旧存在着性能问题，也就是说，只要getInstance方法被调用，那么就会执行同步这个操作，于是我们加个判断，当instance没有被实例化的时候，也就是需要去实例化的时候才去同步。

四、instance为何要有volatile 修饰：

这个问题就涉及到了编译原理，所谓编译，就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java，它的目标代码不是本地机器代码，而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指，在不改变原来语义的情况下，通过调整语句顺序，来让程序运行的更快。这个过程成为reorder。

JVM实现可以自由的进行编译器优化。而我们创建变量的步骤：

1、申请一块内存，调用构造方法进行初始化。

2、分配一个指针指向这块内存。

而这两个操作，JVM并没有规定谁在前谁在后，那么就存在这种情况：线程A开始创建SingletonClass的实例，此时线程B调用了getInstance()方法，首先判断instance是否为null。按照我们上面所说的内存模型，A已经把instance指向了那块内存，只是还没有调用构造方法，因此B检测到instance不为null，于是直接把instance返回了——问题出现了，尽管instance不为null，但它并没有构造完成，就像一套房子已经给了你钥匙，但你并不能住进去，因为里面还没有收拾。此时，如果B在A将instance构造完成之前就是用了这个实例，程序就会出现错误了。

在JDK 5之后，Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前，volatile是个关键字，但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整，读变量不能和之后的读写代码调整！因此，只要我们简单的把instance加上volatile关键字就可以了。

转载请标明出处：http://77blogs.com/?p=488

参考链接：http://blog.51cto.com/devbean/203501

分类：设计模式

Android设计模式—观察者模式

应用场景

优点

缺点

单例模式的双重检测