PHP5以及其设计模式节选（PHPChina翻译）

network

PHP5以及其设计模式节选（PHPChina翻译）

因为工作的关系，一直抽不出时间来翻译一些经典的文章。
PHP5的开发节奏（设计模式）的英文版已经发表了很长时间，但是一直没能翻译完。但是因为文章比较长。所以先把前面翻译的一部分贴上来，让大家共享。如果有觉得哪里的翻译不够精确，可以随时跟我联系，共同学习！
--------------------------------------------------
编者按：此文章的原作者是：Matt Zandstra。文章所说的是设计模式，即如何提高开发的效率，实现模块解决方案继承和共享。

关于作者：

在十年中，Matt Zandstra曾经是一个网络开发工程师，顾问和作者，并且一直传播着面向对象的开发理念。Matt的著作有SAMS Teach Yourself PHP in 24 Hours（已经出了第三版本），并且对动态的HTML有着很大的贡献。同时，Matt也为Linux Magazine和Zend.com撰写文章。Matt一直在使用着PHP,Perl和Java来实现在线应用。现在他是伦敦Yahoo的一个工程师。

----------------------------------
目录
本文的对象
介绍
设计模式的基础知识
• 什么是设计模式？
• 开发模式发展的30年
• 模式和隐藏的内容
开发模式的架构
在开始讨论之前：为什么要用模式呢？
开发模式的概念
• 写的是用户接口而不是执行代码
• 继承基础上特点合成的优势
• 压缩了变量的概念
实际工作中的开发模式的概念：例子说明
总结
书写符号说明
关于本文的作者


本文的对象

这篇文章的读者需要了解PHP的对象、类、继承性等基本概念。如果想对本文有更加清楚认知，读者需要对PHP的面对对象的技术和组件配置有更多的理解。


介绍

就算你从没有看过模式日志类似的文档，你也应该在最近几年里接触过“设计模式”这个词语。甚至，你曾经认为模式只不过是一时的潮流罢了。但是在新旧两个世纪交替后，突然之间，任何地方都有了模式的影子。显然，PHP中也是如此。而且，随着PHP5开始全面支持对象，设计模式已经成为PHP程序员的一个基础工具。
在这片文章里我介绍的模式是基于PHP5的，基于这个基础的定义我引用了一个简短的例子。我也对模式的架构作了描述和解释了经典模式的发展和应用的一些概念。


设计模式的基础知识

为了展开对模式的讨论，我们需要先介绍了一下背景细节。在这个部分，你将获得总的概念，从而帮助你理解整篇文章。别着急，我们会在接下来介绍重点内容的。


什么是设计模式？

作为一个程序员，你总是一次又一次地碰到了商业要求。比如，需要处理更多的数据库，或者是处理一个HTTP请求以便相对应地进行合适的操作。类似的要求决定了解决方案，解决方案又决定了你的代码的结构和框架。当你第一次碰到类似问题的时候，你也许要花上不少时间去辛苦地思考这个解决方案。最后，当你再次分析这个解决方案的时候，你很可能会重新定义它，甚至会完全代替它。你会选择一个更加灵巧的解决方案或者是一个在你的整个系统上有更高的效率的解决方案。
然后，你很容易感觉到你的系统的运行需要不少的控件，然后采用了一系列的技术去实现。同时，你采用的每个技术都会产生新的需求。比如，你正在实现HTTP请求的处理，你需要一个能够根据不同的请求激发不同操作的智能组件。此时，你需要小心翼翼地对一些源代码进行修改，而不是简单地进行复制粘贴就可以的。
但是如果你使用了模式，这一切将变得简单易行。比如你加入了一个新的团队的时候；或者在不知道某个技术确切的名字的时候去需要描述它的时候；或者你离开一个团队后，接替你工作的人如何了解你的系统。试想一下，当你正在为实现一个功能的代码冥思苦想的时候，很有可能别人也经历过，并且找到了解决的办法。所以如果你能够得到他们记录下来的结论，很显然地，你将可以节省大量的时间。
如果你设计一个系统，你需要使用设计模式。设计模式日志是最精华的结论，也是最通用、最实用的。而且这神奇的命名和定义并不是神话，是的，但是他们是神奇的。
这里有一个我钟爱的关于设计模式的定义：
在软件的世界里，模式是最能表现一个团队设计理念和经验的最贴切的概念。

(Grady Booch, Core J2EE Patterns)
设计模式就是这样。他们是许多通用的解决方案，并且被精确地记录下来以便团队里面其他的成员可以共享。这意味遇到相同问题的时候，他们就不用一次又一次地去寻找解决方案，而是可以直接采用设计模式里面的已经得出的结论。
如何来编写设计模式呢？下面列出了一个通常需要的部分：
一个设计模式描述了一个需求和一些基于系统的解决方案。
每个设计模式包含了三个基本的元素：问题，解决方案和说明文档。

问题
一些有经验的程序员知道真正的工作并不是去修正一个bug而是在寻找代码。借助设计模式的的帮助，对一个问题需求的理解超过了简单地选择工具并实现它。一个设计模式就具备了关于该问题需求的讨论和总结。
有不少针对设计模式的评价说因为设计模式，技术的应用变得不恰当。这也许是一个公正的评论，但是这并不足以阻碍设计模式的使用。一个设计模式可以迅速地定为出一个问题需求的解决方案。然后，一个优秀的程序员可以轻松地进行引用和配置。
请看 Gang of Four 关于设计模式的评述:
在过去的一年，更重要的一个改变就是就是设计模式处理问题的能力得到了更大的重视。使用设计模式来解决问题非常的容易，同时技术的应用和重复利用业变得非常容易。虽然，描述一个模式的应用环境并把它能解决的问题详细地描述出来说明它是一个最好的解决方案不是一件容易的事。但是总体来说了解一个人在做什么和理解他为什么这么做对比起来，了解还是容易些。当然，知道一个模式的效果同样是重要的，因为这样能帮助我们选择应用的模式。同时，这样还能帮助我们去理解现有系统的模式。一个模式的作者需要定义出一个模式能解决的具体问题和具体问题的特点，任何一个人都需要对他建立的模式做此说明。
(Gamma et al, 设计模式)
解决方案
这个部分很容易被认为就是一个设计模式了。很容易理解的，因为整个设计模式的命名和这个部分的命名是相同的。使用设计模式实现的就是简单地嵌入解决方案，然后分析它的效果和变化。
一个模式的解决方案经常以多种方式来表达。它在一些实际的例子被描述出来，并且被赋予了恰当的定义。类似的描述经常是通过图表的形式实现的（使用了全球通用的标准语言来表达类、对象和交互性）。同时一个设计模式还包含了说明性的代码例子，并且代码例子一般都是由一种或者多种面向对象的语言编写的。
重要的是你需要把设计模式和一般的食谱等区别开来。因为你很难简单地把一个设计模式里面的代码复制到一个项目里面。一个解决方案是一个整体并不是一些小的有用的代码片断。当一个设计模式采用了一些代码后，所有的代码将互相合作来实现一个整体的概念和应用。所以不要认为一个设计模式里面的代码都是随便就放采用的。
文档
一个设计模式的适用范围是通过它提供的文档进行描述的。也有一些是例外的，但是大多数是用文档来实现的。但是如果你采用了其它的组件描述的适用范围，当你应用该设计模式的时候，你就需要设置一些新的条件，然后你可能会因此去分析新的条件会导致什么结果。这一切就像设计模式自己描述一样。这种情况下，你很有可能被误导认为需要另一个组件来解决问题了。上述的内容也往往被一些批评家用来评价模式的借口。


设计模式发展的30年
虽然设计模式有些像关于需求问题的简单的讨论，从而觉得它是无处不在，并且不受时间限制的。但是，一个设计模式还是有着它自己的形式的习惯。这些最早是从一个叫做克里斯多佛-亚历山大的学者开始的。 他在20世界的70年代就开始使用开发模式了。最初，他使用设计模式来描述一个架构的元素。这个架构是一个从文学角度来描绘我们的生活和工作的框架。而亚历山大定义了这些模式因此一般的概念和技术可以被方便快速地总结组合起来并可以被分享。
每一个模式都描述了一个在我们的环境里屡次发生的问题，并介绍了解决方案的核心部分。这样即使你使用了一百万次该模式来解决问题，都有可能找不到两次解决的办法是相同的。
(Christopher Alexander, A Pattern Language)

到了80年代后，因为一些面向对象编程使用了包含了设计模式的SmallTalk语言来进行开发，设计模式开始慢慢地显示出它的科学价值。向对计算机技术来说，人类许多的工艺是经历了几百年甚至是上千年的发展形成的，所以一个下士或者是一个木匠可以方便地引用一些经验来告诉自己应该怎么做。但是计算机技术的发展却没有悠久历史沉淀下来的经验可以借鉴，所以面向对象的编程技术在显示出明显的技术优势时，也发现了最为一个新兴学科面临的挑战。
随着C++和Java的出现，设计模式得到了长足地发展。并且，尽管开发语言总是不停地在升级换代，设计模式总是会被保留。而且，被保留下来的不仅仅是设计模式的思想，许多设计模式也被保留了下来并实现了跨语言应用。
1995年，Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides 编写了《设计模式：面向对象的软件的可重复使用的元素》一书，并在书中出现了许多模式的核心。他们四个人也因此被称为“四人组合”，他们的书也被戏称为Gang of Four book, 或者是GOF。这些设计模式都是结合Smalltalk和C++里面的。并且在Java诞生的时候，Java的基础也含有类似模式的元素。
到了90年代末，大多数的设计模式的书都是用Java来举例子的。但是，还是有许多的设计模式日志是用其它的语言来举例说明的，这其中当然包含了PHP。四人组合也是继续成为最著名的支持语言最多的面向对象编程的书。
随着PHP4在世纪之交时发布，关键的面向对象的开发最终变成可能。即使如此，这种开发方法的流行程度也使得PHPcommunity的一些人觉得惊奇。早在PHP3的时候，类就被通过相关数组集成在PHP的外部扩展当中。尽管PHP4仍然不能提供完全的支持，在PHP中类的使用性能还是得到了很大的提高。并且，随着PHP的开发者把类内嵌到第三方的资源中（PHP中的PEAR），因此面向对象的代码可以非常快速地被执行并且发展了起来。利昂. Atkinson 在Zend.com 介绍了设计模式，Harry Fuecks 建立了它的站点phppatterns.com.
如果说PHP4只是重复了别的语言对面向对象的应用， PHP 5 就是把设计模式完全融合到平台中了。首先， 它成了PHP的一部分。设计模式甚至在PHP手册被详细地介绍。Zend engine也为此做了明显地改动，很大一部分就是增加对类的支持。这些性能的提高也有相关的文档进行描述，最重要的是这些类已经成为了PHP的核心之一。因此，这些也为程序员提供了许多有效地工具，和许多设计模式。


设计模式和隐含的内容

我已经向大家阐述了设计模式和面向对象的编程，以及它们两者相辅相成的关系。事实是，在大多数的设计模式的文档里都有专门的面向对象的解决方案。除了少数例外的，比如- Martin Fowler's Transaction Script pattern springs to mind – 但是这些往往是用来证明规则的。
设计模式的日志不仅仅是包含了类和对象，它还涵盖了设计模式的一些重要的概念。下面就列出相关的部分。


设计模式的架构

设计模式的形式是多样的，所以它同样存在着关于那个才是最好的讨论。一些程序员比如Martin Fowler 喜欢一些不上特别严谨的比较随意的方案。也有其他一些人比如Gang of Four这样的，使用非常严谨的模块来定义。下面就列出Gang of Four 的一些部分：
•        目的： 使用一到两个句子来概括设计模式。概括出来后，可以在列表形式中使用。
•        动机： 问题描述，一般是通过例子体现出来的。
•        适用性： 设计模式解决方案的适用环境分析。
•        组成： 用一个 UML 类型的图标来表示系统的组成部分和相互之间的关系。
•        参与/协作： 设计模式描述的各个组件，以及它们之间是如何配合工作。
•        逻辑关系： 每一个设计的决定都有着它利益和局限性。这与你希望通过该设计模式来达到的效果是互相关联的。
•        执行： 关于解决方案的完善的讨论。
•        代码片段： 一段面向对象的代码例子。代码的执行环境类似于现实中碰到的环境。
•        使用： 设计模式不是被创造出来的，而是被发现出来的。也就是说，一个设计模式从发现到被广泛认可，需要一个过程来证明它确实是有效的，在这个过程当中有个规律经常被用到：就是一个设计模式最起码能够被应用到三个以上的需求中。
•        相关模式：不同的设计模式之间的交互性是很强的。这个部分列出的是那些需要加入的和建议加入的其它设计模式。

------------------------------------------------------
下面开始的是：“讨论下为什么要使用设计模式？”，待续！

qrst529

看帖人~有素质！~我“顶”




























我总在牛A与牛C之间徘徊!西游Q记西游Q记西游Q记希望OL秦始皇