Observer模式深度探索

微软顶级技术大师Jeffrey Richter的作品，一向是不容错过的。为了帮助开发者这篇专论Observer模式的文章也不例外。Observer模式是经典设计模式中应用最为广泛也最为灵活多变的模式之一。本文在.NET技术框架下深入发掘了Observer模式的内涵，值得细细品味。

　　虽然设计模式并不是万能丹，但确实是一个非常强大的工具，开发人员或架构师可使用它积极地参与任何项目。设计模式可确保通过熟知和公认的解决方案解决常见问题。模式存在的事实基础在于：大多数问题，可能已经有其他个人或开发小组解决过了。因此，模式提供了一种在开发人员和组织之间共享可使用解决方案的形式。无论这些模式的出处是什么，这些模式都利用了大家所积累的知识和经验。这可确保更快地开发正确的代码，并降低在设计或实现中出现错误的可能性。此外，设计模式在工程小组成员之间提供了通用的术语。参加过大型开发项目的人员都知道，使用一组共同的设计术语和准则对成功完成项目来说是至关重要的。最重要的是，如果能正确地使用，设计模式可以节省您大量的时间。

　　.NET框架模式

　　虽然GoF的示例仅限于C++和Smalltalk，但设计模式并不与特定语言或开发平台捆绑在一起；Microsoft .NET框架的出现为分析设计模式提供了新的机会和环境。在框架类库(FCL)的开发过程中，Microsoft应用了很多GoF模式。由于.NET框架中提供的功能范围非常广泛，因此，还开发和提出了一些全新的模式。

　　我们对设计模式的研究从Observer模式入手。

　　Observer模式

　　面向对象的开发的一个主导原则是，在给定的应用程序中正确地划分任务。系统中的每个对象应该将重点放在问题域中的离散抽象上。简而言之，一个对象只应做一件事，而且要将它做好。这种方法可确保在对象之间划定清晰的界限，因而可提供更高的重用性和系统可维护性。

　　一个特别重要的领域是用户界面和基础业务逻辑之间的交互。在应用程序的开发过程中，需要快速更改用户界面，并且不能对应用程序的其他部分产生连带影响，这是司空见惯的事。此外，业务要求也可能会发生变化，而这一切与用户界面无关。具有丰富开发经验的人都知道，在很多情况下，这两组要求都会发生变化。如果没有划分UI和应用程序其他部分，修改任一部分都会对整体造成不利的影响。

　　很多应用程序都需要在用户界面和业务逻辑之间划分清晰的界限。因此，自GUI出现以后，很多面向对象的框架均支持将用户界面从应用程序的其他部分中划分出来。其中的大部分应用程序采用的设计模式几乎相同。这种模式通常称为观察者，它非常有助于在系统中各种对象之间划分清晰的界限。此外，还会经常看到在框架或应用程序中与UI无关的部分中使用这种解决方案。Observer模式的作用远远超过了其最初的想法。

　　逻辑模型

　　虽然Observer模式有很多变体，但该模式的基本前提包含两个角色：观察者(observer)和主体(subject)（熟悉Smalltalk MVC的人将这些术语分别称为View和Model）。在用户界面的环境中，观察者是负责向用户显示数据的对象。另一方面，主体表示从问题域中模拟的业务抽象。正如图1中所描述的一样，在观察者和主体之间存在逻辑关联。当主体对象中发生更改时，（例如，修改实例变量），观察者就会观察这种更改，并相应地更新其显示。



　　例如，假定我们要开发一种简单的应用程序，来跟踪全天的股票价格。在此应用程序中，我们指定一个Stock类来模拟在NASDAQ交易的各种股票。该类包含一个实例变量，它表示在全天不同时段经常波动的股价。为了向用户显示此信息，应用程序使用一个StockDisplay类向stdout（标准输出）写信息。在此应用程序中，一个Stock类实例作为主体，一个StockDisplay类实例作为观察者。随着股价在交易日中随时间发生变化，Stock实例的当前股价也会发生变化（它怎样变化并不重要）。因为StockDisplay实例正在观察Stock实例，所以在这些状态发生变化（修改股价）时，就会向用户显示这些变化。

　　通过使用这种观察过程，可以在Stock和StockDisplay类之间划分界限。假定应用程序的要求第二天发生变化，要使用基于窗体的用户界面。要启用此新功能，只需要构造一个新类StockForm作为观察者。无论发生什么情况，Stock类都不需要进行任何修改。事实上，它甚至不知道发生此类更改。类似地，如果需求变化要求Stock类从另一个来源检索股价信息（可能是从Web服务，而不是从数据库中检索），则StockDisplay类不需要进行修改。它只是继续观察Stock就够了。