本文共 1640 字,大约阅读时间需要 5 分钟。
关于观察者模式比较简单,网上解释的很多很多,解释的都挺好理解的,因此这里并不打算说明太多,有关实现和案例源码已上传至。欢迎加星关注,后续会有持续更新。design-patterns提供了两种实现方案,一种是,一种是。
本文的关注点在于领域模式的封装,重点在于jdk的实现,和自己实现的区别,各自优势分析。下面是我在分析时想到的10个问题,理解自己综合分析后的理解。
Observable是一个类,可以直接继承Obervable,直接调用addObserver方法添加观察者,观察者实现update(Observable o, Object arg)方法。
没有使用泛型,直接使用的Object。如果使用泛型,则会让Observer丧失掉扩展性,因为Observer同时订阅多个目标时,无法保证每个目标的通知对象都是同一个类。在实现update方法中,根据Observable来判定是哪个目前的更新消息,并通过instanceof 来判断Object的类型,并强制转化后使用
在继承Observable的类中,调用addObserver方法
从面向接口编程的角度来看,其实是有的,主题对象Observable会保存所有Observer,具体观察者会实现Observer的update方法。但是这一层依赖是松耦合的
从实现难度上来说,jdk自带的观察者模式并不难,且和自己实现起来的方式差别不大。
不一定,看自己业务需要和代码层次。不建议混在一起,可以有个单独的类介于两者之间来做这件事情,
推为主,拉为次。一般推的数据已经很全的,但是也有可能数据太多只推一部分,业务根据各自需求,来从arg中获取,或另外通过RPC接口回调拉数据
这边会限制Observable的使用,目标对象必须extendsObservable。由于java不可多继承类,所以在考虑类的继承实现关系上需要注意。但是本人认为这是Observable的一个优势,因为Observable已经帮忙实现了很多逻辑。但是如果在java8中,如果这个类可以换为接口,通过default方法提供目前JDK1.0就已经提供的功能,那就真是完美了。见common-utils的design-patterns模块的com.common.observer.jdk18包下实现
对多个Observable调用addObserver方法,在Observer的update的实现中,对Observable的类型进行判断是哪个Observable目标,对不同目标,使用不同的处理逻辑。这里给出了实现源码,
这里我的理解还不能说服自己,所以先把这篇文章给大家
转载地址:http://bhnqb.baihongyu.com/