php教程：php设计模式之编程惯用法

我希望经过上面的讨论后，你也会被带动起来——“测试引导”(Test Infected)！（这个术语，原创于Erich Gamma，详细情况请见文章http://junit.sourceforge.net/doc/testinfected/testing.htm），就象Gamma所写的那样，刚开始你可能会感到测试是很繁琐的，但是当你为你的程序搭建好一个广阔的测试集后，你将你的代码更加自信！

重构

即使最有思想性且最熟练的程序员也不能预见一个软件项目中的任何细微之处。问题总是出乎意外的出现，需求也可能在变化，结果是代码被优化，共享然后代替。

重构是一个惯用的方法：检查你所有的代码，找出其中能统一化和简单化的共同或者类似之处，使得你的代码更加容易维护和扩展。重构也包括探索一个设计模式是否能够应用到这个具体的问题上——这也能使解决方案简单化。

重构，简单点说是重命名一个属性或者方法，复杂点说是压缩一个已有的类。改变你的代码使得它符合一个或者更多的设计模式是另外一种重构——读完这本书后，你可能会去实现的。

没有什么能比例子来更好的解释重构了！

让我们考虑两个简单的类：CartLine和Cart。CartLine记录了购物车里面每个项目的单件价格和数量。比如CartLine可能记录着“四见红色的polo衬衣，每件19.99contentrdquo;。Cart 是一个容器，用来装载一个或者更多的CartLine对象并执行一些相关的计算工作，比如购物车里面的所有商品的总花费。

下面是CartLine和Cart的简单实现：

// PHP5
class CartLine {
public $price = 0;
public $qty = 0;
}
class Cart {
protected $lines = array();
public function addLine($line) {
$this->lines[] = $line;
}
public function calcTotal() {
$total = 0;
// add totals for each line
foreach($this->lines as $line) {
$total += $line->price * $line->qty;
}
// add sales tax
$total *= 1.07;
return $total;
}
}

重构的第一步必须有足够的测试来覆盖你所有的代码。这样才能保证你修改的代码不能产生和你原来代码不同的结果。顺便提一下，除非你改变了需求（你代码期望的结果）或者在测试实例中发现了错误，你的测试代码是是不能改变的。

下面是一个测试CartLine和Cart的例子，它在重构的过程中是不会改变的。

function TestCart() {
$line1 = new CartLine;
$line1->price = 12; $line1->qty = 2;
$line2 = new CartLine;
$line2->price = 7.5; $line2->qty = 3;
$line3 = new CartLine;
$line3->price = 8.25; $line3->qty = 1;
$cart = new Cart;
$cart->addLine($line1);
$cart->addLine($line2);
$cart->addLine($line3);
$this->assertEqual(
(12*2 + 7.5*3 + 8.25) * 1.07,
$cart->calcTotal());
}

看着上面的代码，你可能会发现它们有一些“code smells”(代码臭味)——有着古怪的样子而且看起来好像是有问题的代码——它们就像重构的候选项。（更多关于code smells的资料请看http://c2.com/cgi/wiki?codesmell）。两个最直接的重构候选者是注释和计算（与销售税等相关的计算）。重构的一种形式：析取函数（Extract Method）将把这些难看的代码从cart::calcTotal()中提取出来，然后用一个合适的方法来替代它，从而使得代码更加简洁。

比如，你可以增加两个计算方法：lineTotal()和calcSalesTax()：

protected function lineTotal($line) {
return $line->price * $line->qty;
}
protected function calcSalesTax($amount) {
return $amount * 0.07;
}

现在你可以重写calcTotal()函数：

public function calcTotal() {
$total = 0;
foreach($this->lines as $line) {
$total += $this->lineTotal($line);
}
$total += $this->calcSalesTax($total);
return $total;
}

到目前为止的改动都是有意义的（至少在这个例子的上下文中），它对于再次暂停和运行这些代码来验证结果依然正确是很有帮助的。记得，一个绿色的成功条的显示出来了！（译者注：本章开始时，作者提及到：绿色的条意味着测试都通过了。）

然而，目前的代码依然有一些可以挑剔的地方。其中一个就是在新方法lineTotal()中存取公共属性。很明显计算每行的之和的责任不应该属于Cart类，而应该在类CartLine里面实现。

再次重构，在CartLine中增加一个新的方法total()用来计算订单里面的每个项目的长期价钱。

public function total() {
return $this->price * $this->qty;
}

然后从类Cart中移除方法lineTotal()，并改变calcTotal()方法来使用新的cartLine::Total()方法。重新运行这个测试，你依然会发现结果是绿色条。

全新重构后的代码就是这样：

class CartLine {
public $price = 0;
public $qty = 0;
public function total() {
return $this->price * $this->qty;
}
}
class Cart {
protected $lines = array();
public function addLine($line) {
$this->lines[] = $line;
}
public function calcTotal() {
$total = 0;
foreach($this->lines as $line) {
$total += $line->total();
}
$total += $this->calcSalesTax($total);
return $total;
}
protected function calcSalesTax($amount) {
return $amount * 0.07;
}
}

现在这代码不再需要每行注释了，因为代码本身更好的说明了每行的功能。这些新的方法，更好的封装了计算这个功能，也更加容易适应将来的变化。（比如说，考虑不同大的销售税率）。另外，这些类也更加平衡，更容易维护。

这个例子显然是微不足道的，但是希望你能从中推断并预想出如何重构你自己的代码。

在编码的时候，你应该有出于两种模式中的一种：增加新的特征或者重构代码。当在增加特征的时候，你要写测试和增加代码。在重构的时候，你要改变你原有的代码，并确保所有相关的测试依然能正确运行。

关于重构的主要参考资料有Martin Fowler著作的《重构：改进原有代码的设计》（Refactoring:Improving the Design of Existing Code）。用一些精简点来总结Fowler的书，重构的步骤如下所示：

定义需要重构的代码
有覆盖所有代码的测试
小步骤的工作
每步之后都运行你的测试。编码和测试都是相当重复的——和编译型语言相比，解释型语言，比如PHP是容易很多的。
使用重构来使你的代码有更好的可读性和可修改性。

其他实践

下面还有集中其他的实践习惯值得提及到的，也值得加入到你自己的编程习惯里面的。

UML

统一建模语言（UML）是一种与具体编程语言无关的用来描述面对对象编程观念的方法。关于UML的相关信息资料你可以从http://www.uml.org上找到。

UML涉及到很多方面，但对PHP程序员来说，其中最相关的两方面是类图和序列图。

类图描述了一个或者更多的类以及他们在你的程序之间的相互关系。（译者注：最好能够参考相关的UML教材，将有助于你的理解。）每个类都用一个盒子标识，每个盒子都分成三部分：第一部分是类名，第二步分列举了类的属性（变量），最后一部分列举了类的方法。属性和方法的可见度被设计为：＋代表public（公开），—代表private（私有），#代表protected（受保护的）。

序列图描述了为一个特定的任务或者事件，你对代码中的对象之间的典型的交互活动。一个序列图主要传达这样的信息：谁，以什么样的顺序，在什么时候，调用不同的方法（由名字也可以看出：“序列图”）。序列图是对象集和开发人员之间交互沟通的非常有用工具。

在我自己的工程里，我使用这两种典型的类图来勾画我们的设计，但是很少能将他们格式化到项目文档里面。对象之间的关系经常随着你对系统理解的深化和用户需求的变化而改变，因此这些图表很快就会过时。这也就是说“一张图足足值一千个文字”。这些图表对新开发人员理解系统是非常由帮助的，也能做为使用你软件的开发人员的手册。

资源控制

“及时的、经常性的保存”是开发人员另外一个有用的格言。即使你是这个项目的唯一的开发人员，你也应该维持所有的资源处于控制下。

网上可以获取到很多关于资源控制的解决方法，其中两个出色：CVS（http://www.cvshome.org）和Subversion（http://subversion.tigris.org）。CVS是一个非常流行的用于解决PHP和Apache项目的工具。同时，Subversion也正在迅速的成为流行的二选一工具之一，因为它克服了CVS的一些不足之处（特别是在原语命令和删除/重命名文件夹或文件方面）。然而很少有项目安装Subversion服务器。

在工作的时候，我采用CVS，但这本书的代码都是使用Subversion来维护的。

资源代码文档

如果你浏览完了这本书的所有页面，你可以会注意到一些明显的格式化的注释块类似于：

/**
* funny multi-line comments
* @something what is this?
*/

它们被称为“docblocks”（译者注：文档块），是由程序，比如说phpDocumentor（http://phpdocu.sf.net），为你的PHP项目自动生成的应用程序接口（API）文档。

Docblocks（文档块）是特定格式的多行注释，以/**标识开始，接下来的每行都以*为第一个字符，并以*/标识注释终止。在每行的前缀前面允许有空格。

@something 代表一个“标签”(tag)，当文档需要转化为解析格式时，标签用来阐明一些必要的信息。比如说标签@private，使用在php4中，常用来标识类的这个方法或者属性时私有的，因为在php4中时没有提供这种天然的能力的（译者注：在php4中时无法说明一个变量或者方法是否私有的）。

资源代码文档比如说docblocks即是一个有用的参考资料，也是开源项目的一个好广告。其中一个例子（我帮忙维护的）就是SimpleTestAPI文档（http://simpletest.org）。

<?php
// PHP4
// the subject code
define(‘TAX_RATE’, 0.07);
function calculate_sales_tax($amount) {
round($amount * TAX_RATE,2);
}
// include test library
require_once ‘simpletest/unit_tester.php’;
require_once ‘simpletest/reporter.php’;
// the test
class TestingTestCase extends UnitTestCase {
function TestingTestCase($name=’’) {
$this->UnitTestCase($name);
}
function TestSalesTax() {
$this->assertEqual(7, calculate_sales_tax(100));
}
}
// run the test
$test = new TestingTestCase(‘Testing Unit Test’);
$test->run(new HtmlReporter());

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!