本文实例分析了PHP代码重构方法。分享给大家供大家参考，具体如下：
随着 PHP 从一种简单的脚本语言转变为一种成熟的编程语言，一个典型的 PHP 应用程序的代码库的复杂性也随之增大。为了控制对这些应用程序的支持和维护，我们可以使用各种测试工具来自动化该流程。其中一种是单元测试，它允许您直接测试所编写代码的正确性。然而，通常遗留代码库是不适合进行这种测试的。本文将介绍对包含常见问题的 PHP 代码的重构策略，以便简化使用流行的单元测试工具进行测试的过程，同时减少改进代码库的依赖性。
简介
回顾 PHP 的发展历程，我们发现它已经从一个简单的用来替代当时流行的 CGI 脚本的动态脚本语言变成一种成熟的现代编程语言。 随着代码库的增长，手动测试已经变成不可能完成的任务，无论是大是小，所有代码的变化都会对整个应用程序产生影响。这些影响可能小到只是影响某个页面的加 载或表单保存，也可能是产生难以检测的问题，或者产生只在特定条件下才会出现的错误。甚至，它可能会使以前修复的问题重新出现在应用程序中。为此开发了许 多测试工具来解决这些问题。
其中一种流行的方法是所谓的功能或验收测试，它会通过应用程序的典型用户交互来测试这个应用程序。这是一种 很适合测试应用程序中各个进程的方法，但是测试过程可能非常慢，而且一般无法测试底层的类和方法是否按要求正常工作。这时，我们需要使用另一种测试方法， 那就是单元测试。单元测试的目标是测试应用程序底层代码的功能，保证它们执行后产生正确的结果。通常，这些 “不断增大” 的 Web 应用程序会慢慢出现越来越多久而久之难以测试的遗留代码，这使开发团队很难保证应用程序测试的覆盖率。这通常被称为 “不可测试代码”。现在让我们看看如何识别应用程序中的不可测试代码，以及修复这些代码的方法。
识别不可测试的代码
关于代码库不可测试性的问题域通常在编写代码时是不明显的。当编写 PHP 应用程序代码时，人们倾向于按照 Web 请求的流程来编写代码，这通常就是在应用程序设计时采用一种更加流程化的方法。急于完成项目或快速修复应用程序都可能促使开发人员 “走捷径”，以便快速完成编码。以前，编写不当或者混乱的代码可能会加重应用程序中的不可测试性问题，因为开发人员通常会进行风险最小的修复，即使它可能产生后续的支持问题。这些问题域都是无法通过一般的单元测试发现的。
依赖全局状态的函数
全局变量在 PHP 应用程序中很方便。它们允许您在应用程序中初始化一些变量或对象，然后在应用程序的其他位置使用。然而，这种灵活性是有代价的，过度使用全局变量是不可测试代码的一个通病。我们可以在 清单 1中看到这种情况。
清单 1. 依赖于全局状态的函数
<"htmlcode"><"color: #ff0000">无法重置的单一实例单一实例指的是旨在让应用程序中一次只存在一个实例的类。它们是应用程序中用于全局对象的一种常见模式，如数据库连接和配置设置。它们通常被认为是应用程序的禁忌， 因为许多开发人员认为创建一个总是可用的对象用处不大，因此他们并不太注意这一点。这个问题主要源于单一实例的过度使用，因为它会造成大量不可扩展的所谓 god objects 的出现。但是从测试的角度看，最大的问题是它们通常是不可更改的。清单 3就是这样一个例子。
清单 3. 我们要测试的 Singleton 对象
<"htmlcode"><"color: #ff0000">使用类构造函数进行单元测试的一个良好做法是只测试需要测试的代码，避免创建不必要的对象和变量。您创建的每一个对象和变量都需要在测试之后删除。这对于文件和数据库表等 麻烦的项目来说成为一个问题，因为在这些情况下，如果您需要修改状态，那么您必须更小心地在测试完成之后进行一些清理操作。坚持这一规则的最大障碍在于对 象本身的构造函数，它执行的所有操作都是与测试无关的。清单 5 就是这样一个例子。
清单 5. 具有一个大 singleton 方法的类
<"htmlcode"><"color: #ff0000">经硬编码的类依赖性正如我们在前一节介绍的，造成测试困难的大量类设计问题都集中在初始化各种不需要测试的对象上。在前面，我们知道繁重的初始化逻 辑可能会给测试的编写造成很大的负担（特别是当测试完全不需要这些对象时），但是如果我们在测试的类方法中直接创建这些对象，又可能造成另一个问题。清单 7显示的就是可能造成这个问题的示例代码。
清单 7. 在一个方法中直接初始化另一个对象的类
<"htmlcode"><"font-size: medium">可测试代码的好处显然，编写更具可测试性的代码肯定能够简化 PHP 应用程序的单元测试（正如您在本文展示的例子中所看到的），但是在这个过程中，它也能够改进应用程序的设计、模块化和稳定性。我们都曾经看到过 “spaghetti” 代码，它们在 PHP 应用程序的一个主要流程中充斥了大量的业务和表现逻辑，这毫无疑问会给那些使用这个应用程序的人造成严重的支持问题。在使代码变得更具可测试性的过程中， 我们对前面一些有问题的代码进行了重构；这些代码不仅设计上有问题，功能上也有问题。通过使这些函数和类的用途更广泛，以及通过删除硬编码的依赖性，我们 使之更容易被应用程序其他部分重用，我们提高了代码的可重用性。此外，我们还将编写不当的代码替换成更优质的代码，从而简化将来对代码库的支持。
结束语
在本文中，通过 PHP 应用程序中一些典型的不可测试代码示例，我们了解了如何改进 PHP 代码的可测试性。我们还介绍了这些情况是如何出现在应用程序中的，然后介绍了如何恰当地修复这些问题代码来便于进行测试。我们还了解了这些代码的修改不仅 能够提高代码的可测试性，也能够普遍改进代码的质量，以及提高重构代码的可重用性。
更多关于PHP相关内容感兴趣的读者可查看本站专题：《php面向对象程序设计入门教程》、《PHP数组(Array)操作技巧大全》、《PHP基本语法入门教程》、《PHP运算与运算符用法总结》、《php字符串(string)用法总结》、《php+mysql数据库操作入门教程》及《php常见数据库操作技巧汇总》
希望本文所述对大家PHP程序设计有所帮助。
标签：PHP,代码重构
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com狼山资源网 Copyright www.pvsay.com暂无“PHP代码重构方法漫谈”评论...