JDK Observer设计模式研究

目前设计模式的介绍性文章越来越多,但设计模式的研究性文章仍然比较欠缺,这着实让人觉得有点遗憾。本文旨在抛砖引玉,具体分析一下java中jdk自带的observer设计模式(下文如没特别指出,observer设计模式就意指java中jdk自带的observer设计模式)的实现。

1.Observer设计模式概要

Observer设计模式在GOF里属于行为设计模式。JDK里提供的observer设计模式的实现由java.util.Observable类和java.util.Observer接口组成。从名字上可以清楚的看出两者在Observer 设计模式中分别扮演的角色:Observer是观察者角色,Observable是被观察目标(subject)角色。

Observable是一个封装subject基本功能的类,比如注册observer(attach功能),注销observer(detatch功能)等。这些功能是任何一个扮演observerable角色的类都需要实现的,从这一点上来讲,JDK里将这些通用功能专门封装在一个类里,显得合情合理。通常情况下,我们的类只要从Observerable类派生就可以称为observerable角色类,使用非常简单。

2.使用observer设计模式存在的困难

但我们不得不注意到,在项目实际开发当中,情况往往要复杂得多。java不支持多继承特性在很多时候是阻碍我们使用observer设计模式的绊脚石。比如说,我们设计的一个类已经是某个类的派生类,在这种情况下同时想让它扮演observerable角色将变得麻烦。如何实现“多继承”的效果是摆在我们面前的一大难题。下面我们首先分析一下Observable类。

3.Observable类“触发通知”的原理

Observable必须“有变化”才能触发通知observer这一任务,这是它的本质体现。查看源码便可知一二。Observerable部分源码如下:

//……省略……
   private boolean changed = false;
   //……省略……
   public void notifyObservers(Object arg) {
   //……省略……
     Object[] arrLocal;
     synchronized (this) {
      //……省略……
      if (!changed)
       return;
       arrLocal = obs.toArray();
       clearChanged();
     }
   //……省略……
   protected synchronized void setChanged() {
    changed = true;
   }

   protected synchronized void clearChanged() {
    changed = false;
   }

正如粗的斜体标注部分所示,在notifyObservers(Object arg) 方法里if (!changed) return;语句告诉我们,若changed属性值为false,将直接返回,根本不会触发通知操作。并且我们注意到changed 属性被初始化为false,这将意味着如果我们不主动设置changed属性为true,将不会有任何变化,也就是说根本起不到“通知”作用。因此,设置changed属性的值是我们应用jdk observer 设计模式的关键所在。那么如何才能设置changed属性呢?从源码可以看出,唯一的入口是通过setChanged()。下面我们分析一下changed属性及相关的方法setChanged()和clearChanged()。

4.Observable类的分析

Observable#changed属性的初始值为false,这很容易理解,不再详细陈述。细心的读者可能会注意到跟changed属性有关的两个方法setChanged()和clearChanged(),它们的修饰符都是protected。想强调的是,是protected,而不是public。但这样是否有其必要性和合理性?答案是肯定的。在前面的分析中,我已经提到,setChanged()方法是设置changed的唯一入口,它的修饰符定义为protected,就意味着通过定义Observable的对象,再设置changed属性将变得不可能。从这个意义上说,要想应用observer设计模式,必须继承Observable类方可。关于这一点,下文还会提及。但是,为什么不能定义成public?这似乎难以理解。因为定义成public,我们不就可以很方便地设置changed属性的值吗?为了弄清楚这个问题,我们还是看一下Observable里的相关的代码:

//……省略……
   public void notifyObservers(Object arg) {
   //……省略……
    for (int i = arrLocal.length-1; i>=0; i--)
     ((Observer)arrLocal[i]).update(this, arg);
   }
    

 

这段代码表达的意思是说找出所有已注册的Observer,再逐个进行“通知”,通过调用Observer#update(Observable,Object)方法进行通知。我们看到,update 第一个参数是this,我们同时还必须注意到,这段代码是Observable类里的代码。这就相当于是在一再强调,发出“通知”的,必须是observable自己(Observable类或者其派生类),其它任何类都不行。这就意味着我们的observable类继承Observable类是必要的,因为如果不继承,而采用组合的话,将无法保证能传递好this。换句话说,采用组合的方式使用Observable类,将变得几乎没有任何意义。同时,修饰符定义为protected,可以确保是在Obsrvable里进行触发通知的,不会在其它任何地方进行通知,这显得内敛性很强。如果将setChanged()修饰符定义为public,将无法保证正确“传递this”的硬性要求,这不符合“只有observalbe才能直接或间接通知observer”这一observable设计模式的硬性要求。由此我们可见一斑,jdk的很多理念的思想性是多么的强。

时间: 2024-08-29 10:57:17

JDK Observer设计模式研究的相关文章

基于SOA的电子政务云顶层设计模式研究与实现

基于SOA的电子政务云顶层设计模式研究与实现 曲阜师范大学  朱贵丽 本文在深入研究电子政务和顶层设计的基础上,基于SOA思想,整合云服务计算模式,提出了一种面向全局的电子政务解决方案.主要体现在以下几个方面: 1.在分析当今电子政务系统存在的各种瓶颈问题基础上,提出了一种基于SOA的电子政务云总体架构. 2.借鉴美国电子政务顶层设计,在业务集成.应用集成等方面进行探索的基础上,提出了一种现代电子政务系统服务构件的分类模式. 3.基于电子政务顶层设计方案,给出了网上审批系统的顶层设计,并从子系统

.NET设计模式研究之装饰模式

设计 概述 在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性:并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀.如何使"对象功能的扩展"能够根据需要来动态地实现?同时避免"扩展功能的增多"带来的子类膨胀问题?从而使得任何"功能扩展变化"所导致的影响将为最低?这就是本文要讲的Decorator模式. 意图 动态地给一个对象添加一些额外的职责.就

.NET下的设计模式研究之桥接模式

设计 概述 在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种"多维度的变化"?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式. 意图 将抽象部分与实现部分分离,使它们都可以独立的变化.[GOF <设计模式>] 结构图 图1 Bridge模式结构图 生活中的例子 桥接模式将抽象部分与它的实现分离,使它们能够独立地变化.一个普通的开关控制的电灯.电风扇等等,都是桥接的例子.开

C#设计模式之Observer设计模式(观察者设计模式)

一.观察者(Observer)模式 观察者模式又叫做发布-订阅(Publish/Subscribe)模式.模型-视图(Model/View)模式.源-监听器(Source/Listener)模式或从属者(Dependents)模式. 观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象.这个主题对象在状态上发生变化时,会通知所有观察者对象,使它们能够自动更新自己. 一个软件系统常常要求在某一个对象的状态发生变化的时候,某些其它的对象做出相应的改变.做到这一点的设计方案有很

Java设计模式研究之Flyweight模式

GOF:运用共享技术有效地支持大量细粒度的对象. 解释一下概念:也就是说在一个系统中如果有多个相同的对象,那么只共享一份就可以了,不必每个都去实例化一个对象.比如说(这里引用GOF书中的例子)一个文本系统,每个字母定一个对象,那么大小写字母一共就是52个,那么就要定义52个对象.如果有一个1M的文本,那么字母是何其的多,如果每个字母都定义一个对象那么内存早就爆了.那么如果要是每个字母都共享一个对象,那么就大大节约了资源. 在Flyweight模式中,由于要产生各种各样的对象,所以在Flyweig

设计模式(Patterns in Java)

设计 板桥里人的设计模式讲解是国内媒体(包括书籍和网站)中最早的成体系介绍,本系列介绍纯为免费传播(转载本站文章,请保留作者和网址),尽量做到言简意赅,通俗易懂,但是难免有所疏漏敬请来信或论坛讨论,不断完善. 真正掌握设计模式需要在实践中不断研究和使用,关于设计模式在具体实例的应用,可以阅读板桥里人的书籍<Java实用系统开发指南>.书籍中8个实例都从设计模式.框架等高度对系统进行崭新的设计和实现,这种应用理念正是现在以及将来软件设计和编程的根本之道. 1:前言 学习GoF设计模式的重要性 建

《设计模式解析(第2版•修订版)》目录—导读

作者简介 设计模式解析(第2版•修订版) Alan Shalloway 美国Net Objectives咨询/培训公司的创始人和CEO.他是麻省理工学院的计算机科学硕士,具有30多年面向对象咨询.培训和软件开发的经验,并经常受邀在重要的软件开发会议(包括SD Expro.Java One.OOP和OOPSLA)上演讲. James R. Trott 美国一家大型金融机构的资深顾问.他是应用数学科学硕士.MBA和跨文化研究硕士.在其20年的职业生涯中,他一直将面向对象和基于模式的分析技术运用在知识

JavaServer Faces框架使用的设计模式

server|设计 本文中,作者 Anand Joshi 使用 JSF 框架中的设计模式阐释了 JavaServer Faces (JSF) 体系结构.他讨论了 JSF 体系结构中使用的 GoF 设计模式,以及这些模式在 JSF 框架中的作用.任何对设计模式和 JSF 体系结构有一定了解的人都能从 Anand 详细的介绍中有所收获.*读者应该对 GoF 设计模式和 JSF 技术有很好的了解. 设计模式可以帮助用户在更高层次上抽象细节,更好地理解体系结构.如果比较熟悉 GoF 设计模式和 Java

探索JSF框架中使用的设计模式

js|设计 设计模式可以帮助用户在更高层次上抽象细节,更好地理解体系结构.如果比较熟悉 GoF 设计模式和 JavaServer Faces (JSF) 框架,本文可以帮助您洞察 JSF 框架中使用的设计模式,深入理解其工作原理. 本文探讨了 JSF 框架中使用的设计模式.详细讨论的设计模式包括 Singleton.Model-View-Controller.Factory Method.State.Composite.Decorator.Strategy.Template Method 和 O