编程设计模式设计模式

Java设计模式之观察者模式

2019-07-13  本文已影响0人  singlezero

Java设计模式之观察者模式

本文仅是个人观点,如有错误请指正

简介

当对象间存在一对多关系时,可以考虑使用观察者模式(Observer Pattern)。比如,当一个对象被修改时,则会自动通知它的依赖对象。观察者模式属于行为型模式。

实现

接下来将用三个例子来说明观察者模式,详细代码可以参考文末的地址。

需求

现在有一个气象站,想对外发布数据,有一个公司知道后想要通过天气站的数据建立一个天气看板,这就交给了公司的开发小王,小王拿到需求后,很快就开始行动了,下面就是小王的实现方法

好了看起来需求已经满足了,开始使用吧,然而没过多久,另外一个公司也和天气站联系上了,想要他们提供的天气数据来展示明天的天气,小王一听便说那还不简单,去weather类里面加上你的看板类,加上通知,加上。。

不对啊,这加一个使用者就这么麻烦了,那以后要是来了更多的使用者怎么办?又或者有的使用者突然又不使用这个数据了,想要取消通知怎么办?要是按这样的话改来改去每次修改都要重新上线,会非常麻烦,数据的及时性也得不到保证。小王头疼不已,这时候公司里的老李看到了,笑呵呵的说小王,不要着急,我们再重新看看你写的方法,再想想需要加入的接口和你有什么共同的地方,咱们把它抽离出去,然后再。。。。。小王在老李的帮助下很快做出了第二版实现

我们看到经过老李的一番指导,现在的设计基本上满足了需求,即使新增看板继续继承观察者接口,不需要的观察者就可以直接移除,这样提高了扩展性,去除了之前代码每次新增需要修改代码的弊端,实现了开闭原则。

接着老李又说,小王啊,其实java内置对象中就已经实现了观察者模式我们只需要拿来用就可以了。。。

怎么用呢?请看下面的实现。

果然经过老李一番重构,小王很快就明白了,观察者模式的好处,看着老李地中海的脑袋心想,这或许就是成为大牛的代价吧。。。。

总结

前面讲述了两种观察者模式的实现方法,一个是我们自己写的接口做的实现,另一种是直接使用java中的内置观察者模式实现,两者各有各的优势和缺点,对于一般的情况内置观察者就能满足,但是有一点Observable是一个类不是接口所以只能继承他,但由于java只能对接口多继承,所以使用内置对象的时候需要多继承的时候就不能使用了,自定义的方法可以更灵活,但是需要写更多的代码,鱼和熊掌不可兼得。

链接

本文代码仓库地址:https://gitee.com/singlekingdom/JavaDesignPatterns.git

上一篇下一篇

猜你喜欢

热点阅读