.NET中的设计模式五:观察者模式

观察者模式(Observer)完美的将观察者和被观察的对象分离开。举个例子,用户界面可以作为一个观察者,业务数据是被观察者,用户界面观察业务数据的变化,发现数据变化后,就显示在界面上。面向对象设计的一个原则是:系统中的每个类将重点放在某一个功能上,而不是其他方面。一个对象只做一件事情,并且将他做好。观察者模式在模块之间划定了清晰的界限,提高了应用程序的可维护性和重用性。

观察者模式有很多实现方式,从根本上说,该模式必须包含两个角色:观察者被观察对象。在刚才的例子中,业务数据是被观察对象,用户界面是观察者。观察者和被观察者之间存在“观察”的逻辑关联,当被观察者发生改变的时候,观察者就会观察到这样的变化,并且做出相应的响应。如果在用户界面、业务数据之间使用这样的观察过程,可以确保界面和数据之间划清界限,假定应用程序的需求发生变化,需要修改界面的表现,只需要重新构建一个用户界面,业务数据不需要发生变化。

“观察”不是“直接调用”

实现观察者模式的时候要注意,观察者和被观察对象之间的互动关系不能体现成类之间的直接调用,否则就将使观察者和被观察对象之间紧密的耦合起来,从根本上违反面向对象的设计的原则。无论是观察者“观察”观察对象,还是被观察者将自己的改变“通知”观察者,都不应该直接调用。

实现观察者模式的例子

实现观察者模式有很多形式,比较直观的一种是使用一种“注册——通知——撤销注册”的形式。下面的三个图详细的描述了这样一种过程:

1:观察者(Observer)将自己注册到被观察对象(Subject)中,被观察对象将观察者存放在一个容器(Container)里。

2:被观察对象发生了某种变化(如图中的AskPriceChanged),从容器中得到所有注册过的观察者,将变化通知观察者。

3:观察者告诉被观察者要撤销观察,被观察者从容器中将观察者去除。

观察者将自己注册到被观察者的容器中时,被观察者不应该过问观察者的具体类型,而是应该使用观察者的接口。这样的优点是:假定程序中还有别的观察者,那么只要这个观察者也是相同的接口实现即可。一个被观察者可以对应多个观察者,当被观察者发生变化的时候,他可以将消息一一通知给所有的观察者。基于接口,而不是具体的实现——这一点为程序提供了更大的灵活性。

下面代码是使用C#实现观察者模式的例子:

//“观察者”接口
public interface IObserver {
   void Notify(object anObject);
}

//“被观察对象”接口
public interface IObservable {
   void Register(IObserver anObserver);
   void UnRegister(IObserver anObserver);
}

观察者和被观察对象都分别从这两个接口实现,所有的操作都是由这两个接口定义的,而不是具体的实现。所以观察者和被观察对象没有绑定在一起。我们可以方便的更改观察者和被观察对象的任意部分而不影响其他部分。

下面实现具体的被观察对象。下面的类是所有被观察对象的基类,实现了所有被观察对象都必须的方法。我们使用一个Hashtable作为观察者的容器。代码如下:

//所有被观察对象的基类
public class ObservableImpl : IObservable {
     
   //保存观察对象的容器
   protected Hashtable _observerContainer = new Hashtable();
  
   //注册观察者
   public void Register(IObserver anObserver){
      _observerContainer.Add(anObserver,anObserver);
   }
     
   //撤销注册
   public void UnRegister(IObserver anObserver){
      _observerContainer.Remove(anObserver);
   }

   //将事件通知观察者
   public void NotifyObservers(object anObject) {
      //枚举容器中的观察者,将事件一一通知给他们
      foreach(IObserver anObserver in _observerContainer.Keys) {
         anObserver.Notify(anObject);
      }
   }
}

上面的类不是最终要实现的被观察对象,而是所有被观察者的基类,其中实现了所有观察对象共有的功能。这个类可以干脆定义为abstract,使得程序员不可以创建其实例。接口以及实现这个接口的虚类既保持了类之间松散的耦合,又使多个具体实现可以使用相同的功能。

下面最终实现观察者模式,使用用户界面——业务数据作为例子:

//业务数据(被观察对象)
public class SomeData : ObservableImpl {
   //被观察者中的数据
   float _askPrice;

   //改变数据的属性
   public float AskPrice {
      set {
         _askPrice = value;
         base.NotifyObservers(_askPrice);//将改变的消息通知观察者
      }
   }
}

//用户界面(观察者)
public class SomeKindOfUI : IObserver {
   public void Notify(object anObject){
      Console.WriteLine("The new ask price is:" + anObject);
   }
}

//实际调用的过程
public class MainClass{
   public static void Main() {
      //创建观察者和被观察者
      SomeKindOfUI ui = new SomeKindOfUI();
      SomeData data = new SomeData();

      //在被观察对象中注册观察者
      data.Register(ui);

      //改变被观察对象中的数据,这时被观察者会通知观察者
      data.AskPrice = 1000f;

      //注销观察者,停止观察
      stock.UnRegister(stockDisplay);
   }
}

.NET中更好的实现方式

上面的形式是我们用一种最基本的方式实现了观察者模式,我们为观察者模式开发了一种特定的类型。在.NET框架中,使用代理以及事件,可以更好的实现观察者模式。C#中代理和事件的介绍可以看这一篇文章:在C#中使用代理的方式触发事件,里面有对代理和事件的详细描述,还有例程,这里就不多说了。在.NET支持的其他语言中也有各自的实现方式。

在事件的模式下,声明事件的类就是被观察者。被观察者不需要实现对观察者的注册,只需要公开一个事件,而不实行任何操作。被观察者也不需要将自己注册到观察对象中,而是要创建一个特定的代理的实例,将这个代理绑定到某个方法上。用这样的方式注册或者撤销观察者对观察对象的观察。仔细研究代理和事件的模式就不难发现,IObserver和IObservable接口的方法可以减少观察者和观察对象之间的耦合,而代理和事件几乎消除了这两个模块之间的耦合,灵活性提高了很多。

参考文献

探究观察者设计模式 Doug Purdy(Microsoft Corporation) Jeffrey Richter(Wintellect)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
面向对象技术课程设计大纲一、题目1、观察者模式 网上商店形式多样,每个站点有自己的特色,但也有其一般的共性,单就"商品的变化,以便及时通知订户"这一点,是很多网上商店共有的模式,这一模式类似Observer patern观察者模式.具体的说,如果网上商店商品在名称 价格等方面有变化,如果系统能自动通知会员,将是网上商店区别传统商店的一大特色.这就需要在商品product加入Observer这样角色,以便product细节发生变化时,Observer能自动观察到这种变化,并能进行及时的update动作.2、适配器模式 小小最爱喝饮料,可妈妈不让,每天都用保温杯给她晾白开水,她自己想了个办法,偷偷地开水杯的水倒掉,然后将饮料倒进水杯内,以后她就特别爱喝“白开水”了。这就是适配器模式的思想。3、外观模式如果把医院作为一个子系统,按照部门职能,这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道,就如同一个子系统的客户端与一个子系统的各个类打交道一样,不是一件容易的事情。首先病人必须先挂号,然后门诊。如果医生要求化验,病人必须首先划价,然后缴款,才能到化验部门做化验。化验后,再回到门诊室。解决这种不便的方法便是引进门面模式。可以设置一个接待员的位置,由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是外观模式的体现,病人只接触接待员,由接待员负责与医院的各个部门打交道。 4、桥接模式一杯咖啡为例,子类实现类为四个:杯加奶、大杯加奶、 杯不加奶、大杯不加奶。但是,我们注意到:上面四个子类有概念重叠,可从另外一个角度进行考虑,这四个类实际是两个角色的组合:抽象 和行为,其抽象为:杯和大杯;行为为:加奶不加奶(如加橙汁 加苹果汁). 实现四个子类在抽象和行为之间发生了固定的绑定关系,如果以后动态增加加葡萄汁的行为,就必须再增加两个类:杯加葡萄汁和大杯加葡萄汁。显然混乱,扩展性极差。那我们从分离抽象和行为的角度,使用Bridge模式来实现。 面向对象技术课程设计大纲一、题目1、观察者模式 网上商店形式多样,每个站点有自己的特色,但也有其一般的共性,单就"商品的变化,以便及时通知订户"这一点,是很多网上商店共有的模式,这一模式类似Observer patern观察者模式.具体的说,如果网上商店商品在名称 价格等方面有变化,如果系统能自动通知会员,将是网上商店区别传统商店的一大特色.这就需要在商品product加入Observer这样角色,以便product细节发生变化时,Observer能自动观察到这种变化,并能进行及时的update动作.2、适配器模式 小小最爱喝饮料,可妈妈不让,每天都用保温杯给她晾白开水,她自己想了个办法,偷偷地开水杯的水倒掉,然后将饮料倒进水杯内,以后她就特别爱喝“白开水”了。这就是适配器模式的思想。3、外观模式如果把医院作为一个子系统,按照部门职能,这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道,就如同一个子系统的客户端与一个子系统的各个类打交道一样,不是一件容易的事情。首先病人必须先挂号,然后门诊。如果医生要求化验,病人必须首先划价,然后缴款,才能到化验部门做化验。化验后,再回到门诊室。解决这种不便的方法便是引进门面模式。可以设置一个接待员的位置,由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是外观模式的体现,病人只接触接待员,由接待员负责与医院的各个部门打交道。 4、桥接模式一杯咖啡为例,子类实现类为四个:杯加奶、大杯加奶、 杯不加奶、大杯不加奶。但是,我们注意到:上面四个子类有概念重叠,可从另外一个角度进行考虑,这四个类实际是两个角色的组合:抽象 和行为,其抽象为:杯和大杯;行为为:加奶不加奶(如加橙汁 加苹果汁). 实现四个子类在抽象和行为之间发生了固定的绑定关系,如果以后动态增加加葡萄汁的行为,就必须再增加两个类:杯加葡萄汁和大杯加葡萄汁。显然混乱,扩展性极差。那我们从分离抽象和行为的角度,使用Bridge模式来实现。 <b

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值