探究观察者的设计模式docx.docx

简介 在开发给定项目的过程中，通常会使用设计模式概念来解决与应用程序设计和结构有关的某些问题。 但是，设计模式定义通常很难准确地表达信息；因此，此概念保证了对起源和历史情况提供简短的说明。 软件设计模式的起源归因于 Christopher Alexander 所做的工作。 作为架构师，Alexander 注意到在给定的环境中存在常见问题及其相关的解决方案。 Alexander 将此问题/解决方案/环境三元组称为“设计模式”，架构师在构建设计过程中可通过它以统一的方式快速解决问题。 二十五年前第一次出版的 A Pattern Language: Towns, Buildings, Construction （Alexander 等人编著，牛津大学出版社于 1977 年出版）介绍了 250 多种建筑设计模式，并提供了将此概念融入软件开发领域的基本原则。 在 1995 年，软件业首次广泛采用了设计模式，因为它们与构建应用程序直接相关。 四位作者 Gamma、Helm、Johnson 和 Vlissides（统称为四人组或 GoF）将 Alexander 的设计模式与他们的作品 Design Patterns: Elements of Reusable Object-Oriented Software （Addison-Wesley 出版公司于 1995 年出版）中的刚刚兴起的面向对象的软件开发动向结合起来。 凭着他们丰富的经验和对现有对象框架的分析，GoF 提供了 23 种设计模式，这些模式分析了在设计和构造应用程序时遇到的常见问题和解决方案。 在这个出版物之后，设计模式的概念已发展为包含在软件领域中遇到的很多 问题和解决方案。 事实上，设计模式的广泛采用导致了反模式概念的出现，这些模式是指通常会使手头问题更加严重而不加解决问题的解决方案。 为什么要使用设计模式？ 虽然设计模式并不是万能钥匙（如果世上真有此物 的话），但它是一个非常强大的工具，开发人员或架构师可使用它积极地参与任何开发项目。 设计模式可确保通过熟知和公认的解决方案解决常见问题。 模式存在的事实基础在于：大多数问题其他个人或开发小组可能已经遇到并解决了。 因此，模式提供了一种在开发人员和组织之间共享可使用的解决方案的机制。 无论这些模式的出处是什么，这些模式都利用了大家所积累的知识和经验。 这可确保更快地开发正确的代码，并降低在设计或实现中出现错误的可能性。 此外，设计模式在工程小???成员之间提供了通用的语义。 参加过大型开发项目的人员都知道，使用一组共同的设计术语和准则对成功完成项目来说是至关重要的。 最重要的是，设计模式可以节省您大量的时间 （如果正确使用的话）。 观察者模式 虽然 GoF 将他们的示例限制在 C++ 和 Smalltalk，但设计模式并不专门与给定语言或开发平台捆绑在一起；Microsoft .NET 框架的出现为分析设计模式提供了新的机会和环境。 在框架类库 (FCL) 的开发过程中，Microsoft 应用了很多 GoF 于 1994 年首次提出的相同模式。由于 .NET 框架中提供的功能范围非常广泛，因此，还开发和提出了一些全新的模式。 在本系列文章中，我们将详细 介绍 FCL 中涉及的一些设计模式。 我们将考虑每种模式的一般结构和优点，然后介绍 FCL 中的具体实现情况。 虽然我们介绍的大多数模式出自 GoF，但是，.NET 框架提供了很多新颖的功能，目前尚没有或几乎没有相应的设计原则。 我们还将介绍与这些新功能相关的设计模式。 我们对设计模式的研究从观察者模式入手。 观察者模式 面向对象的开发的一个主导原则是，在给定的应用程序中正确 地分配任务。 系统中的每个对象应该将重点放在问题域中的离散抽象上，而不是放在任何其它方面。 简而言之，一个对象只应做一件事，而且要将它做好。 这种方法可确保在对象之间划定清晰的界限，因而可提供更高的重用性和系统可维护性。 一 个正确划分任务特别重要的领域就是，用户界面和基础业务逻辑之间的交互。 在应用程序的开发过程中，需要快速更改用户界面要求，并且不会对应用程序的其他部分产生连带影响，这是司空见惯的事。 此外，业务要求也可能会发生变化，而这一切与用户界面无关。 具有丰富开发经验的人都知道，在很多情况下，这两组要求都会发生变化。 如果没有划分 UI 和应用程序其他部分，修改任一部分都会对整体造成不利的影响。 很多应用程序都会遇到以下常见问题：需要在用户界面和业务逻辑之间划分清晰的 界限。 因此，自 GUI 出现以后开发的很多面向对象的框架均支持将用户界面从应用程序的其他部分中划分出来。 不要惊讶（可能有一点），其中的大部分应用程序采用类似的设计模式来提供此功能。 这种模式通常称为观察者，它在系统中的各种对象