设计模调HObserver.docVIP

设计模式:Observer（观察器） 本页内容 上下文 问题 影响因素 解决方案 示例 结果上下文 相关模式上下文 在面向对象的编程中，对象同时包含数据和行为，这两者一起表示业务域的特定方面。使用对象生成应用程序的优点之一是可以将所有数据操作封装在对象内。这样，就使对象成为独立的单位，并增加了在其他应用程序中重用对象的可能性。但是，对象无法在孤立状态下工作。在除最不重要的应用程序之外的所有应用程序中，对象必须协作才能完成更复杂的任务。当对象协作时，对象可能必须在对象状态发生更改时互相通知对方。例如，Model-View-Controller 模式规定将业务数据（模型）与显示逻辑（视图）分离。当模型发生改变时，系统必须通知视图以便它可以刷新可视显示，并准确地反映模型的状态。换句话说，视图依赖于模型，以便获知模型内部状态的更改。 返回页首 问题 一个对象如何将状态更改通知其他对象，而又不依赖于这些对象的类？ 返回页首 影响因素 要解决此问题，就必须协调下列影响因素和注意事项： 将状态更改通知依赖对象的最容易的方法是直接调用它们。但是，对象之间的直接协作需要让它们的类建立相互的依赖性。例如，如果模型对象调用视图对象以便将更改通知它，则模型类现在也会依赖于视图类。两个对象之间的这种直接耦合（也称为紧耦合）降低了类的可重用性。例如，每当要重用模型类时，还必须重用视图类，因为模型会调用它。如果有多个视图，问题就更复杂了。 在事件驱动的框架中，经常出现需要耦合类的情况。框架必须能够将事件通知应用程序，但是框架不能依赖于特定应用程序类。 同样，如果对视图类进行了更改，则模型很可能受到影响。包含许多紧耦合类的应用程序往往是脆弱的和难于维护的，因为一个类中的更改可能影响所有的紧耦合类。 如果直接调用依赖对象，则在每次添加新依赖项时，都必须对源对象内的代码进行修改。 在某些情况下，依赖性对象的数目在设计时可能是未知的。例如，如果您允许用户打开某个特定模型的多个窗口（视图），则必须在模型状态改变时更新多个视图。 直接的函数调用仍然是在两个对象之间传递信息时效率最高的方式（仅次于让两个对象的功能同时包含在同一个对象中）。因此，使用其他机制将对象功能分隔开来很可能对性能有负面影响。取决于应用程序的性能要求，您可能必须对此进行权衡。 返回页首 解决方案 使用 Observer 模式在独立的对象（主体）中维护一个对主体感兴趣的依赖项（观察器）列表。让所有观察器各自实现公共的 Observer 接口，以取消主体和依赖性对象之间的直接依赖关系（见图 1）。 同样，如果对视图类进行了更改，则模型很可能受到影响。包含许多紧耦合类的应用程序往往是脆弱的和难于维护的，因为一个类中的更改可能影响所有的紧耦合类。 图 1:基本的 Observer 结构 在与依赖性对象相关的客户端中发生状态更改时，ConcreteSubject会调用 Notify() 方法。Subject 超类用于维护所有感兴趣观察器组成的列表，以便让 Notify()方法能够遍历所有观察器列表，并调用每个已注册的观察器上的 Update() 方法。观察器通过调用 Subject上的 subscribe()和 unsubscribe() 方法，来注册到更新和取消注册（见图 2）。ConcreteObserver的一个或多个实例可能也会访问 ConcreteSubject 以获取详细信息，因此通常依赖于 ConcreteSubject类。但是，如图 1 所示，ConcreteSubject 类既不直接也不间接依赖于 ConcreteObserver 类。 图 2:基本的 Observer 交互 使用在主体和观察器之间进行通信这种普通方法，可以动态而不是静态地构建协作。由于将通知逻辑与同步逻辑分离，因此可以添加新观察器而不必修改通知逻辑，而且也可以更改通知逻辑而不会影响观察器中的同步逻辑。代码现在的分离程度更高，因此更易于维护和重用。 将更改通知对象而不致于依赖这些对象的类是一项很常见的要求，因此，某些平台提供了语言支持来执行此功能。例如，Microsoftreg; .NET Framework 定义了委托和事件这两个概念以实现 Observer 角色。因此，很少需要在 .NET 中显式地实现 Observer 模式，而应该使用委托和事件。大多数 .NET 开发人员会将 Observer 模式视为实现事件的复杂方式。 图 1 所示的解决方案显示从 Subject 类继承的 ConcreteSubject 类。在 Subject 类中，实现了添加或删除观察器以及遍历观察器列表的方法。ConcreteSubject必须做的全部工作是继承 Subject，并在发生状态