常用设计者模式---观察者模式

1、什么是观察者模式

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

观察者模式要点有二：主题和观察者。
最贴切的案例是：杂志订阅，杂志是主题，观察者是订阅者。当出版新杂志时候，这个事件会自动通知所有的订阅者。主题和订阅者一般都作为接口。

2、观察者模式的组成

抽象主题角色：把所有对观察者对象的引用保存在一个集合中，每个抽象主题角色都可以有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者角色。一般用一个抽象类和接口来实现。
抽象观察者角色：为所有具体的观察者定义一个接口，在得到主题的通知时更新自己。
具体主题角色：在具体主题内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个子类实现。
具体观察者角色：该角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。通常用一个子类实现。如果需要，具体观察者角色可以保存一个指向具体主题角色的引用。

3、观察者简单实现

观察者模式这种发布-订阅的形式我们可以拿微信公众号来举例，假设微信用户就是观察者，微信公众号是被观察者，有多个的微信用户关注了程序猿这个公众号，当这个公众号更新时就会通知这些订阅的微信用户。好了我们来看看用代码如何实现：

抽象观察者（Observer）

里面定义了一个更新的方法：

public interface Observer {
    public void update(String message);
}

具体观察者（ConcrereObserver）

微信用户是观察者，里面实现了更新的方法：

public class WeixinUser implements Observer {
    // 微信用户名
    private String name;
    public WeixinUser(String name) {
        this.name = name;
    }
    @Override
    public void update(String message) {
        System.out.println(name + "-" + message);
    }


}

抽象被观察者（Subject）

抽象主题，提供了attach、detach、notify三个方法：

public interface Subject {
    /**
     * 增加订阅者
     * @param observer
     */
    public void attach(Observer observer);
    /**
     * 删除订阅者
     * @param observer
     */
    public void detach(Observer observer);
    /**
     * 通知订阅者更新消息
     */
    public void notify(String message);
}

具体被观察者（ConcreteSubject）
微信公众号是具体主题（具体被观察者），里面存储了订阅该公众号的微信用户，并实现了抽象主题中的方法：

public class SubscriptionSubject implements Subject {
    //储存订阅公众号的微信用户
    private List<Observer> weixinUserlist = new ArrayList<Observer>();

    @Override
    public void attach(Observer observer) {
        weixinUserlist.add(observer);
    }

    @Override
    public void detach(Observer observer) {
        weixinUserlist.remove(observer);
    }

    @Override
    public void notify(String message) {
        for (Observer observer : weixinUserlist) {
            observer.update(message);
        }
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        SubscriptionSubject mSubscriptionSubject=new SubscriptionSubject();
        //创建微信用户
        WeixinUser user1=new WeixinUser("杨影枫");
        WeixinUser user2=new WeixinUser("月眉儿");
        WeixinUser user3=new WeixinUser("紫轩");
        //订阅公众号
        mSubscriptionSubject.attach(user1);
        mSubscriptionSubject.attach(user2);
        mSubscriptionSubject.attach(user3);
        //公众号更新发出消息给订阅的微信用户
        mSubscriptionSubject.notify("刘望舒的专栏更新了");
    }
}

结果

杨影枫-刘望舒的专栏更新了
月眉儿-刘望舒的专栏更新了
紫轩-刘望舒的专栏更新了

4、程序实例（下面是Head First的例子，是一个气象站，用户订阅气象信息的服务。）

并且，最终用户所要的信息可能是：                                    

针对这个需求，应用观察者模式来实现，但是这个只是一个主题与观察者的设计，观察者自身还需要将信息显示出去。那么再用一个接口，专门来实现展示的功能。实际上，下面的DisplayElement接口用再此处，本质上是策略模式的应用。

先从建立接口开始：

public interface Subject{
    // registerObserver和removeObserver都需要一个观察者作为变量，该观察者是用来注册或被删除的
    void registerObserver(Observer o);
    void removeObserver(Observer o);
    // 当主题状态改变时。这个方法会被调用，以通知所有的观察者
    void notifyObservers();
}
 
public interface Observer {
    // 当气象观测值改变时，主题会把温度、湿度、气压的状态值当作方法的参数，传送给观察者
    public void update(float temp, float humidity, float pressure);
}
 
public interface DisplayElement {
    // 当布告板需要显示时，调用此方法
    public void display();
}

实现WeatherData类：

// WeatherData现在实现了Subject接口
public class WeatherData implements Subject {
    // 我们加上一个ArrayList来记录观察者，此ArrayList是在构造器中建立的。
    public ArrayList observers;
    private float temperature;
    private float humidity;
    private float pressure;
 
    public WeatherData() {
        observers = new ArrayList();
    }
 
    // 当注册观察者时，我们只要把它加到ArrayList的后面即可
    @Override
    public void registerObserver(Observer o) {
        observers.add(o);
    }
 
    // 当观察者想取消注册，我们把它从ArrayList中删除即可
    @Override
    public void removeObserver(Observer o) {
        int i = observers.indexOf(o);
        if (i >= 0) {
            observers.remove(i);
        }
    }
 
    // 在这里，我们把状态告诉每一个观察者
    // 因为观察者都实现了update()，所以我们知道如何通知它们
    @Override
    public void notifyObservers() {
        for (int i = 0; i < observers.size(); i++) {
            Observer observer = (Observer) observers.get(i);
            observer.update(temperature, humidity, pressure);
        }
    }
 
    // 当从气象站得到更新观测值时，我们通知观察者
    public void measurementsChanged(){
        notifyObservers();
    }
 
    public void setMeasurements(float temperature, float humidity, float pressure){
        this.temperature = temperature;
        this.humidity = humidity;
        this.pressure = pressure;
        measurementsChanged();
    }
}

实现目前状况布告板：

// 此布告板实现了Observer接口，所以可以从WeatherData对象中获得改变
// 它也实现了DisplayElement接口，因为我们的API规定所有的布告板都必须实现此接口
public class CurrentConditionsDisplay implements Observer, DisplayElement {
    private float temperature;
    private float humidity;
    private Subject weatherData;
 
    // 构造器需要WeatherData对象（也就是主题）作为注册之用
    public CurrentConditionsDisplay(Subject weatherData){
        this.weatherData = weatherData;
        weatherData.registerObserver(this);
    }
 
    // display()方法就是把最近的温度和湿度显示出来
    @Override
    public void display() {
        System.out.println("Cuttent conditions:" + temperature + "F degrees and " + humidity + "% humidity");
    }
 
    // 当update()被调用时，我们把温度和湿度保存起来，然后调用display()
    @Override
    public void update(float temp, float humidity, float pressure) {
        this.temperature = temp;
        this.humidity = humidity;
        display();
    }
}

测试：

public class WeatherStation {
    public static void main(String[] args){
        // 建立WeatherData对象
        WeatherData weatherData = new WeatherData();
 
        // 建立目前状况布告板
        CurrentConditionsDisplay currentDisplay = new CurrentConditionsDisplay(weatherData);
 
        // 模拟新的气象测量
        weatherData.setMeasurements(80, 65, 30.4f);
        weatherData.setMeasurements(82, 70, 29.2f);
        weatherData.setMeasurements(78, 90, 29.2f);
    }
}

本例仅仅是为了说明这种模式，设计还远不够完美。实际上，主题中应该有一个线程去扫描状态的变化，当变化了，自动去调用measurementsChanged()方法。理解每个模式的特点对交流和设计都有很大帮助，当OO思想境修炼到很高的程度时，应该是忘掉所有的模式，而可以根据需要做出最佳设计，这个程度可以算手中无剑，心中有剑的地步。

5、使用观察者模式的场景和优缺点

使用场景

关联行为场景，需要注意的是，关联行为是可拆分的，而不是“组合”关系。
事件多级触发场景。
跨系统的消息交换场景，如消息队列、事件总线的处理机制。
优点
解除耦合，让耦合的双方都依赖于抽象，从而使得各自的变换都不会影响另一边的变换。
缺点
在应用观察者模式时需要考虑一下开发效率和运行效率的问题，程序中包括一个被观察者、多个观察者，开发、调试等内容会比较复杂，而且在Java中消息的通知一般是顺序执行，那么一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般会采用异步实现。

6、Android中的观察者模式
Android源码中也有很多使用了观察者模式，比如OnClickListener、ContentObserver、android.database.Observable等；还有组件通讯库RxJava、RxAndroid、EventBus；在这里将拿我们最常用的Adapter的notifyDataSetChanged()方法来举例： 
当我们用ListView的时候，数据发生变化的时候我们都会调用Adapter的notifyDataSetChanged()方法，这个方法定义在BaseAdaper中，我们来看看BaseAdaper的部分源码：

public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {

    //数据集观察者
    private final DataSetObservable mDataSetObservable = new DataSetObservable();

    public boolean hasStableIds() {
        return false;
    }

    public void registerDataSetObserver(DataSetObserver observer) {
        mDataSetObservable.registerObserver(observer);
    }

    public void unregisterDataSetObserver(DataSetObserver observer) {
        mDataSetObservable.unregisterObserver(observer);
    }

    /**
     * 当数据集变化时，通知所有观察者
     */
    public void notifyDataSetChanged() {
        mDataSetObservable.notifyChanged();
    }

很明显BaseAdapter用的是观察者模式，BaseAdapter是具体被观察者，接下来看看mDataSetObservable.notifyChanged()：

public class DataSetObservable extends Observable<DataSetObserver> {
    public void notifyChanged() {
        synchronized(mObservers) {
            for (int i = mObservers.size() - 1; i >= 0; i--) {
                mObservers.get(i).onChanged();
            }
        }
    }

我们看到了mObservers，这就是观察者的集合，这些观察者是在ListView通过setAdaper()设置Adaper时产生的：

@Override
    public void setAdapter(ListAdapter adapter) {
        if (mAdapter != null && mDataSetObserver != null) {
            mAdapter.unregisterDataSetObserver(mDataSetObserver);
        }
        ...
        super.setAdapter(adapter);

        if (mAdapter != null) {
            mAreAllItemsSelectable = mAdapter.areAllItemsEnabled();
            mOldItemCount = mItemCount;
            mItemCount = mAdapter.getCount();
            checkFocus();
            //创建数据观察者
            mDataSetObserver = new AdapterDataSetObserver();
            //注册观察者
            mAdapter.registerDataSetObserver(mDataSetObserver);

            ...
        }

接下来看看观察者AdapterDataSetObserver中处理了什么：

class AdapterDataSetObserver extends AdapterView<ListAdapter>.AdapterDataSetObserver {
        @Override
        public void onChanged() {
            super.onChanged();
            if (mFastScroller != null) {
                mFastScroller.onSectionsChanged();
            }
        }

        @Override
        public void onInvalidated() {
            super.onInvalidated();
            if (mFastScroller != null) {
                mFastScroller.onSectionsChanged();
            }
        }
    }

从上面的代码看不出什么，再看看AdapterDataSetObserver的父类AdapterView的AdapterDataSetObserver：

class AdapterDataSetObserver extends DataSetObserver {
        private Parcelable mInstanceState = null;
        @Override
        public void onChanged() {
            mDataChanged = true;
            mOldItemCount = mItemCount;
            mItemCount = getAdapter().getCount();
            if (AdapterView.this.getAdapter().hasStableIds() && mInstanceState != null
                    && mOldItemCount == 0 && mItemCount > 0) {
                AdapterView.this.onRestoreInstanceState(mInstanceState);
                mInstanceState = null;
            } else {
                rememberSyncState();
            }
            checkFocus();
            //重新布局
            requestLayout();
        }

        ...

        public void clearSavedState() {
            mInstanceState = null;
        }
    }

我们看到在onChanged()方法中调用了requestLayout()方法来重新进行布局。好了，看到这里我们都明白了，当ListView的数据发生变化时，我们调用Adapter的notifyDataSetChanged()方法，这个方法又会调用观察者们（AdapterDataSetObserver）的onChanged()方法，onChanged()方法又会调用requestLayout()方法来重新进行布局。

7、我推你拉

拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。

本文参考链接：http://blog.csdn.net/itachi85/article/details/50773358

                           http://www.importnew.com/23507.html

                           http://lavasoft.blog.51cto.com/62575/201617/