浏览 69006 次
锁定老帖子 主题:设计模式之:解剖观察者模式
精华帖 (8) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-07-17
http://www.iteye.com/topic/95124 》的文章中我提到了hibernate中的观察者模式的使用,但是仅仅是一张图而已,今天我就来详细的把对观察者模式的理解阐述出来,希望大家批评指正,欢迎大家拍砖。
[size=9] 论坛上很多人都讲设计模式,也讲了很多设计模式,现在也来说说我对一些设计模式的理解,对于一些简单的模式就不多说了,一切都在我以前写的例子中使用到了,比如说在velocity和freemarker的比较那篇文章里用到了单例,工厂,方法模板,在java邮件,在简单和复杂之间那篇文章里用到了策略,适配,在easywebwork中也使用了几种设计模式,在哪些文章我没有对设计模式进行详细的讲解是因为我觉得那些都是些常用的模式,大家肯定经常见到,一看就明白了,根本用不着讲解,而在那篇《解惑:在spring+hibernate中,只读事务是如何被优化的。
在ibm的技术文章中也有一个老外详细讲解了如何使用aop来增强观察者模式(文章地址见:http://www.ibm.com/developerworks/cn/java/j-aopwork6/ )。 为了便于理解,首先我举一个现实生活中的例子:在快乐男生比赛过程其实就是观察者的一个体现,可以这样说吉杰是一个被观察者,而杨二,包小柏,还有巫启贤就是3个观察者,被观察者操作(唱歌)时,观察者们就开始操作(评分),被观察者唱歌就是通知观察者们进行评分。 GoF说道:Observer模式的意图是“定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新”。从这段话里我们可以得到两个信息,如下: 1, 观察者(具体执行操作的对象,有多个) 2, 被观察者(顾名思义是被观察的对象,如果该对象发生某些变化则通知观察者执行对应的操) 接下来我们看一下附件中的图(请下载附件中的图 http://www.iteye.com/topics/download/eed23def-b8a8-43dc-a753-73d740a3ded0 ),这个图是观察者模式的真实体现,在这个图中有两个类,java.util.Observable,在我们实现观察者模式的时候,我们的被观察者应该继承这个类,这个observable类把持住了被观察者所持有的观察者列表: public class Observable { private boolean changed = false; private Vector obs; //创建被观察者时就创建一个它持有的观察者列表,注意,这个列表是需要同步的。 public Observable() { obs = new Vector(); } /** * 添加观察者到观察者列表中去 */ public synchronized void addObserver(Observer o) { if (o == null) throw new NullPointerException(); if (!obs.contains(o)) { obs.addElement(o); } } /** * 删除一个观察者 */ public synchronized void deleteObserver(Observer o) { obs.removeElement(o); } /** * 通知操作,即被观察者发生变化,通知对应的观察者进行事先设定的操作,不传参数的通知方法 */ public void notifyObservers() { notifyObservers(null); } /** * 与上面的那个通知方法不同的是,这个方法接受一个参数,这个参数一直传到观察者里,以供观察者使用 */ public void notifyObservers(Object arg) { Object[] arrLocal; synchronized (this) { if (!changed) return; arrLocal = obs.toArray(); clearChanged(); } for (int i = arrLocal.length-1; i>=0; i--) ((Observer)arrLocal[i]).update(this, arg); } } 这里只列出了一些常用的操作,大家如有不明白可以自己看java.util包下的Observable,每一个方法前都有详细的解释。但是以上列出的方法对于这个例子来说已经够用了。 当我们自己的被观察者继承这个Observable类是,我们就自动的获取到被观察者的一切条件了。很方便是不是,这也是为什么sun要把Observable放到java.util包中的原因,就是为了方便开发者。 讲完了被观察者再让我们来看看观察者,在上面的代码中有一个addObserver(Observer o)方法,由此我们可以看出来,给被观察者添加观察者时就是用这个方法,那么也就是说观察者一定是Observer的子类或者实现,我们看一下java.util.Observer吧: public interface Observer { /** * This method is called whenever the observed object is changed. An * application calls an <tt>Observable</tt> object's * <code>notifyObservers</code> method to have all the object's * observers notified of the change. * * @param o the observable object. * @param arg an argument passed to the <code>notifyObservers</code> * method. */ void update(Observable o, Object arg); } } 很好,这是一个接口,接口中就只有一个方法,update,方法中有两个参数,Observable和一个object,第一个参数就是被观察的对象,而第二个参数就得看业务需求了,需要什么就传进去什么。我们自己的观察者类必须实现这个方法,这样在被观察者调用notifyObservers操作时被观察者所持有的所有观察者都会执行update操作了(当然如果你override这个方法,你甚至可以指定何种情况下只执行某种observer了,是不是比较像责任链模式了)。 那么到这里我们也差不多可以把观察者模式应用到项目中去了。首先让我们来实现被观察者(因为实现被观察者非常简单) 首先让我们来实现一个发送邮件的观察者: /** * @author 张荣华(ahuaxuan) * @version $Id$ */ public class MailObserver implements Observer{ /** * 这个类取名为MailObserver,顾名思义,她是一个用来发送邮件的观察者 */ public void update(Observable o, Object arg) { System.out.println("发送邮件的观察者已经被执行"); } } 接着再让我们来实现一个发送jms消息的观察者: /** * @author 张荣华(ahuaxuan) * @version $Id$ */ public class JMSObserver implements Observer{ public void update(Observable o, Object arg) { System.out.println("发送消息给jms服务器的观察者已经被执行"); } } 如上所见,观察者的实现完全跟业务相关。是否复杂就得看你得业务是否复杂了。 接下来让我们再来实现被观察者,示例如下: /** * @author 张荣华(ahuaxuan) * @version $Id$ */ public class Subject extends Observable{ /** * 业务方法,一旦执行某个操作,则通知观察者 */ public void doBusiness(){ if (true) { super.setChanged(); } notifyObservers("现在还没有的参数"); } public static void main(String [] args) { //创建一个被观察者 Subject subject = new Subject(); //创建两个观察者 Observer mailObserver = new MailObserver(); Observer jmsObserver = new JMSObserver(); //把两个观察者加到被观察者列表中 subject.addObserver(mailObserver); subject.addObserver(jmsObserver); //执行业务操作 subject.doBusiness(); } } 到此为止,我们已经简单得实现了观察者模式,让我们来运行一下上面main方法,运行结果如下: 发送消息给jms服务器的观察者已经被执行 发送邮件的观察者已经被执行 有了jdk对观察者模式的支持,程序员在实现基本的观察者模式时应该说是易如反掌,这也从一个侧面反应出观察者模式的地位,它的地位应该是非常重要的,引用Nicholas Lesiecki(此人是上面所指的ibm那篇文章的作者)的话说,它是“设计模式中的皇后”。 通过上面的介绍和简单的实例,现在你也可以实现一个自己的观察者了(有时候这个简单的模型并不满足我们的需要,在这种情况下只好自己去写一个类似的但是是为业务定制的observable和observer类了,但显然这中情况并不常见)。事实上spring对观察者模式也有很好的支持(spring可以通过配置文件来执行addobserver方法,这样就可以隐式的把观察者加到被观察者的列表中去了,前提是你的被观察者是spring管理的一个bean之一,详见3楼回复,或者也可以利用afterPropertiesSet方法在被观察者这个bean初始化完成之后立刻把需要的观察者添加进去),除了spring,hibernate中也大量的使用了观察者模式,同时,如果你想再深入一点,可以看看本文第二段给的ibm技术文章的链接。 作者:张荣华,未经作者同意不得随意转载! [/size] 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-07-17
很多系统的事件处理方式就是这种搞法啦。
|
|
返回顶楼 | |
发表时间:2007-07-17
yiding_he 写道 很多系统的事件处理方式就是这种搞法啦。
恩,所以说观察者模式是皇后来着。 在spring中使用观察者模式的方法如下(想想还是补全面一点好,呵呵) <bean id="mailObserver" class="MailObserver"/> <bean id="jmsObserver" class="JMSObserver"/> <bean id="subjectTarget" class="Subject"/> <bean id="subject" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetObject"><ref local="subjectTarget"/></property> <property name="targetMethod"><value>addObserver</value></property> <property name="arguments"> <list> <ref bean="mailObserver"/> <ref bean="jmsObserver"/> </list> </property> </bean> 正如正文末尾所说,这样配置之后,代码中的那些addObserver的调用就不需要了,当你把这个subject注入到你需要的类中时,这个被观察者就自动拥有了她所需要的观察者了,确实很方便 |
|
返回顶楼 | |
发表时间:2008-04-25
讲的非常的详细,,受教了!
不过提个小建议, 楼主的文章对于已经深刻理解模式的人应该说是很好了,可是对一些初学者来说却有点授以鱼的感觉。。 我觉得楼主应该多写一些,模式使用的时机,为什么要使用模式,不使用模式你会遇到什么问题,产生什么样的结果,这样可以加深一些初学者的理解,知道何时可以使用模式,而不是去套用模式。。。 个人建议,希望楼主不要见怪,,个人希望多点文采好的人多写些关于此方面的文章 |
|
返回顶楼 | |
发表时间:2008-05-15
讲的比较清楚了
|
|
返回顶楼 | |
发表时间:2008-05-24
有没有方法防止Observer改变Subject的状态?
如果notifyObserver的函数是 public void update(String a, String b) 这样的参数是不存在这样的问题; 但当传递Subject本身时,如何防止Observer调用Subject的setter方法来改变状态。 比如Observer是显示器,应该只能调用get方法,设计上有没有方法做到这点?除了再构建一个新类只包含Subject的get方法,传递给Observer. |
|
返回顶楼 | |
发表时间:2008-05-28
要是能将一些实际开发中使用的例子就更好了,期待这样的例子
|
|
返回顶楼 | |
发表时间:2008-05-29
在java swing 和awt开发中,观察者模式得到了很广泛深入的应用
|
|
返回顶楼 | |