引用《Android源码设计模式》一书中对观察者模式的总结:
优点:观察者模式主要的作用就是对象解耦,将观察者和被观察者完全隔离,只依赖于Observer和Observable的抽象,可以增强系统的灵活性、可扩展性。
缺点:没有彻底解耦,仍然需要依赖抽象,并且Java中消息的通知默认是顺序执行,一个观察者卡顿,会影响整体的执行效率,在这种情况下,一般考虑采用异步的方式。
其实我没有明白这里说的缺点中,一个观察者的卡顿,会什么会影响整体的执行效率,难道说,必须是调用一个观察者的notify方法结束后,再调用第二个观察者的notify方法?通过本文中的demo,最后打印的log得知,确实如此。
这里总结一下,在android中,观察者模式的一般写法,这里以监听登录状态变化为例。
首先是登录信息类MemberInfoLike:
观察者Observer的抽象接口:
被观察者Observable,或者叫Subject的抽象类 , 其实JDK中也有java.util.Observable,但是并没有提供范型支持,所以,这里是继承自android.database.Observable,其中帮我们维护了一个ArrayList,用来保存当前所有的观察者Observer:
protected final ArrayList<T> mObservers = new ArrayList<T>();
然后MainActivity实现Observer接口,即可在MainActivity监听到登录状态的变化,
随便拖了一个页面布局,两个按钮,模拟登录操作:
为了证明一开始的那个疑问,即是否所有的观察者Observer的notify方法都是顺序同步执行的,打印了log:
得出结论,所有的观察者,都是顺序被回调notify方法的。这应该就是观察者模式的缺点之一,所以一般应该采用异步的方式来实现,以后有时间,应该说是会写异步的观察者模式了,再补上。。。
观察者模式的另外一个缺点就是,没有彻底解耦,抽象的observable仍然依赖抽象的observer,所以,如果要彻底解耦,那么可以参考下文:
后续有时间了,会再加上一篇分析观察者模式在android源码中的使用。