| « | July 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:七月天
日志总数:19
评论数量:84
留言数量:0
访问次数:200633
建立时间:2004年11月4日 |
| |
|
 [设计模式]设计模式（四人帮版）翻译（1） 
读书笔记, 软件技术
torrent 发表于 2005/6/16 18:00:15 |
|
介绍
面向对象软件的设计是困难的，而可重用的面向对象软件的设计则更难。首先必须找出目标对象，按照合适的粒度规入类，并为类定义接口和层次，及在类之间建立合适的关系。设计必须能解决当前的问题，而且要有一定的通用性以满足未来的需求，尽量的避免重新设计。有经验的设计人员将告诉你，在最先的设计中没有良好定义的情况下，要得到一个可重用的灵活的设计是多么的困难。
富有经验的设计人员能做出好的设计，然而新手在可能的选择中犹豫不决，并常常导致采用他们以前用过的非对象技术。新手们要花很长的时间才能学会好的对象程序设计。显然，有经验的设计人员拥有新手们所不拥有的东西，是什么呢？？
专业设计人员所拥有的第一个优势是，不（必）用first原则来解决每一个问题，他们可以采用以前用过的解决方案。当发现一个好的解决方案时，他们一次又一次的使用它。这种经验也是使他们成为专家的原因之一。其结果是，你能够在很多面向对象系统中发现重复出现的类模式和通信对象，这些模式解决了某类特定的设计问题，并使得面向对象的设计变得更加灵活、优雅、最终可重用。熟悉这些模式的设计者可以立即将其应用到设计中而不需要重新发现它们。
象小说家和剧作家就常常任用老的模式如悲剧英雄、浪漫小说等等。同样的，设计者们也经常采用一定的模式如用对象表示状态、装饰对象以添加特征等等。一旦你掌握了设计模式，就能够自动的运用许多设计决策。
我们都知道设计经验的重要性。你是否有过这样的经历，在你设计的过程中碰到了一个似曾相识的问题，如是你搅尽脑汁去回忆是在什么情况下、在什么地方、用什么方法解决的。如果你能回忆起其细节，你就能够重用过去的经验来解决它。然而，我们对这种过去软件设计的经验并没有作出良好的记录以利其他人也能够重用它。
本书的目的就是记录在面向对象软件过程当中的经验，我们称之为设计模式。对每一种设计模式系统的命名、解释和评估，目标是来捕获人们能够有效应用的设计经验的具体形式。为了达到此目的，我们文档化了一些最重要的设计模式。
设计模式使得重用成功的设计和架构更为容易。其Expression Proven方法使得其在新系统中的应用更为容易。设计模式能够帮助你选择那些可重用的设计。通过对类、对象交互及其深层次意图的详细说明，设计模式甚至能提高现有系统的可维护性和文档质量。简言之，设计模式能帮助更快的作出正确的设计。
本书中并未给出新的或未证明的设计模式，这里的设计模式都是那些在不同的系统中多次应用的设计，而大多数这样的设计以前都没有文档化过。它们以前仅在面向对象研究团体中流传，或是成功的面向对象系统中的一些元素，这对于新手来说，每一种方式都不不易学习到。虽然这些设计方法都不是新的，我们以一种新的和可学习的方式来得到它们：作为具有一致格式的一类设计模式。
限于篇幅，本文仅给出专家所知的部分设计模式，不包括那些处理同步、分布式系统和实时系统中的设计模式，也不包括那些针对特定应用领域的设计模式；这里也并不会教你如何建立用户接口、如何写设备驱动、如何处理面向对象数据库。以上所说的领域具有自己独特的模式，值得将来有人为之分类编写。
什么是设计模式？？
Christopher Alexander说过，每一种设计模式都是在讨论一类一次一次重复发生的问题，而规定对这类问题的解决方案的核心部分，。。。。。Alexander所说的模式是在建筑领域，但其对于面向对象设计模式同样适用。在我们的讨论环境中，不过是用对象和接口代替了墙和门窗，但两类设计模式的核心都是针对各自领域中的某类问题的解决方案。
通常，一个模式具有四个关键要素：
模式名（pattern name） 我们用其来规定一类设计问题、对该类问题的解决方案和结果。通过对模式命名扩大了设计词汇，容许我们在设计时采用更高一层的抽象，使得对设计的考虑和交流更为容易。对模式的好的命名是我们工作的难点之一。
问题（problem） 描述了何时使用模式。它解释了问题及其应用环境，可能是对特定设计问题的描述如如何用对象来表示算法，亦可能是对类和对象结构的描述如某种固定的设计中出现的类和对象的结构。有时，问题（）也可以包括条件列表，。。。
解决方案（solution） 解决方案描述了很多基本元素，包括组成设计的元素、以及它们之间的关系、职责和协作。解决方案中不包括具体的设计和实现，因为模式必须应用于不同的环境。取而代之的是，模式提供对某类设计问题和怎样布置这些元素的抽象描述。
后果（consequences） 应用模式的结果和费用的评估。实际上，它是对模式的评估，软件的设计通常关心时间和空间的耗费，后果（）也是选择语言和具体实现的依据之一。由于重用是面向对象的目的之一，模式的后果（）也包括任用该模式在灵活性、可扩展性和轻便性方面的影响。列出后果（）可帮助你更好的理解和评估一个模式。
个人观点影响着对某个设计是不是模式的判断，某人的模式可能只是另一个人的元构建块。本书中我们将模式浓缩为某一级别的抽象，本书的设计模式不包括诸如链表、哈希表一类的可在类中实现和编码的设计，也不包括那些复杂的、针对整个应用或子系统的设计。本书所说的模式是在某一环境中用来解决一种通用设计问题的，类和对象之间通信的描述。
设计模式的命名、抽象描述、以及其设计结构的核心因素的识别，都有助于可重用的面向对象设计。设计模式致力于识别参与的类和实例、它们的角色和协作关系、以及各自的职责。每一个设计模式关注着特定的面向对象设计问题。设计模式描述了何时应用、再有设计约束时能否应用、以及其应用的后果和费用的评估。由于我们必须最后实现设计，设计模式可以用C++，Smalltalk代码来演示。
编程语言的选择非常重要，因为它影响着我们的观点。我们的模式基于C++/Smalltalk语言，这种选择决定了某模式实现的难易。例如，如果我们选择过程语言，我们的设计模式中可能包括类似“继承”、“封装”、“多态”等模式。类似的，我们讨论的有些模式可能为某种语言所直接支持，例如，CLOS中有很多方法就实现了我们所讨论的Visitor模式。实际上，C++和Smalltalk也有很多不同之处，这意味着某个模式可能用某种语言实现起来比另外一种要容易。（例如Iterator模式） |
|
|