本文實例分析了PHP代碼重構(gòu)方法。分享給大家供大家參考，具體如下：

隨著 PHP 從一種簡單的腳本語言轉(zhuǎn)變?yōu)橐环N成熟的編程語言，一個典型的 PHP 應(yīng)用程序的代碼庫的復(fù)雜性也隨之增大。為了控制對這些應(yīng)用程序的支持和維護，我們可以使用各種測試工具來自動化該流程。其中一種是單元測試，它允許您直接測試所編寫代碼的正確性。然而，通常遺留代碼庫是不適合進行這種測試的。本文將介紹對包含常見問題的 PHP 代碼的重構(gòu)策略，以便簡化使用流行的單元測試工具進行測試的過程，同時減少改進代碼庫的依賴性。

簡介

回顧 PHP 的發(fā)展歷程，我們發(fā)現(xiàn)它已經(jīng)從一個簡單的用來替代當時流行的 CGI 腳本的動態(tài)腳本語言變成一種成熟的現(xiàn)代編程語言。 隨著代碼庫的增長，手動測試已經(jīng)變成不可能完成的任務(wù)，無論是大是小，所有代碼的變化都會對整個應(yīng)用程序產(chǎn)生影響。這些影響可能小到只是影響某個頁面的加 載或表單保存，也可能是產(chǎn)生難以檢測的問題，或者產(chǎn)生只在特定條件下才會出現(xiàn)的錯誤。甚至，它可能會使以前修復(fù)的問題重新出現(xiàn)在應(yīng)用程序中。為此開發(fā)了許 多測試工具來解決這些問題。

其中一種流行的方法是所謂的功能或驗收測試，它會通過應(yīng)用程序的典型用戶交互來測試這個應(yīng)用程序。這是一種 很適合測試應(yīng)用程序中各個進程的方法，但是測試過程可能非常慢，而且一般無法測試底層的類和方法是否按要求正常工作。這時，我們需要使用另一種測試方法， 那就是單元測試。單元測試的目標是測試應(yīng)用程序底層代碼的功能，保證它們執(zhí)行后產(chǎn)生正確的結(jié)果。通常，這些 “不斷增大” 的 Web 應(yīng)用程序會慢慢出現(xiàn)越來越多久而久之難以測試的遺留代碼，這使開發(fā)團隊很難保證應(yīng)用程序測試的覆蓋率。這通常被稱為 “不可測試代碼”。現(xiàn)在讓我們看看如何識別應(yīng)用程序中的不可測試代碼，以及修復(fù)這些代碼的方法。

識別不可測試的代碼

關(guān)于代碼庫不可測試性的問題域通常在編寫代碼時是不明顯的。當編寫 PHP 應(yīng)用程序代碼時，人們傾向于按照 Web 請求的流程來編寫代碼，這通常就是在應(yīng)用程序設(shè)計時采用一種更加流程化的方法。急于完成項目或快速修復(fù)應(yīng)用程序都可能促使開發(fā)人員 “走捷徑”，以便快速完成編碼。以前，編寫不當或者混亂的代碼可能會加重應(yīng)用程序中的不可測試性問題，因為開發(fā)人員通常會進行風險最小的修復(fù)，即使它可能產(chǎn)生后續(xù)的支持問題。這些問題域都是無法通過一般的單元測試發(fā)現(xiàn)的。

依賴全局狀態(tài)的函數(shù)

全局變量在 PHP 應(yīng)用程序中很方便。它們允許您在應(yīng)用程序中初始化一些變量或?qū)ο螅缓笤趹?yīng)用程序的其他位置使用。然而，這種靈活性是有代價的，過度使用全局變量是不可測試代碼的一個通病。我們可以在 清單 1中看到這種情況。

清單 1. 依賴于全局狀態(tài)的函數(shù)

?php
function formatNumber($number)
{
  global $decimal_precision, $decimal_separator, $thousands_separator;
  if ( !isset($decimal_precision) ) $decimal_precision = 2;
  if ( !isset($decimal_separator) ) $decimal_separator = '.';
  if ( !isset($thousands_separator) ) $thousands_separator = ',';
  return number_format($number, $decimal_precision, $decimal_separator,
 $thousands_separator);
}

這些全局變量帶來了兩個不同的問題。第一個問題是您需要在測試中考慮所有這些全局變量，保證給它們設(shè)置了函數(shù)可接受的有效值。第二個問題更為嚴重， 那就是您無法修改后續(xù)測試的狀態(tài)并使它們的結(jié)果無效，您需要保證將全局狀態(tài)重置為測試運行之前的狀態(tài)。PHPUnit 有一些工具可以幫您備份全局變量并在測試運行后恢復(fù)它們的值，這些工具能夠幫助解決這個問題。然而，更好的方法是使測試類能夠直接給方法傳入這些全局變量的值。清單 2顯示了采用這種方法的一個例子。

清單 2. 修改這個函數(shù)以支持重寫全局變量

?php
function formatNumber($number, $decimal_precision = null, $decimal_separator = null,
$thousands_separator = null)
{
  if ( is_null($decimal_precision) ) global $decimal_precision;
  if ( is_null($decimal_separator) ) global $decimal_separator;
  if ( is_null($thousands_separator) ) global $thousands_separator;
  if ( !isset($decimal_precision) ) $decimal_precision = 2;
  if ( !isset($decimal_separator) ) $decimal_separator = '.';
  if ( !isset($thousands_separator) ) $thousands_separator = ',';
  return number_format($number, $decimal_precision, $decimal_separator,
 $thousands_separator);
}

這樣做不僅使代碼變得更具可測試性，而且也使它不依賴于方法的全局變量。這使得我們能夠?qū)Υa進行重構(gòu)，不再使用全局變量。

無法重置的單一實例

單一實例指的是旨在讓應(yīng)用程序中一次只存在一個實例的類。它們是應(yīng)用程序中用于全局對象的一種常見模式，如數(shù)據(jù)庫連接和配置設(shè)置。它們通常被認為是應(yīng)用程序的禁忌， 因為許多開發(fā)人員認為創(chuàng)建一個總是可用的對象用處不大，因此他們并不太注意這一點。這個問題主要源于單一實例的過度使用，因為它會造成大量不可擴展的所謂 god objects 的出現(xiàn)。但是從測試的角度看，最大的問題是它們通常是不可更改的。清單 3就是這樣一個例子。

清單 3. 我們要測試的 Singleton 對象

?php
class Singleton
{
  private static $instance;
  protected function __construct() { }
  private final function __clone() {}
  public static function getInstance()
  {
    if ( !isset(self::$instance) ) {
      self::$instance = new Singleton;
    }
    return self::$instance;
  }
}

您可以看到，當單一實例首次實例化之后，每次調(diào)用 getInstance() 方法實際上返回的都是同一個對象，它不會創(chuàng)建新的對象，如果我們對這個對象進行修改，那么就可能造成很嚴重的問題。最簡單的解決方案就是給對象增加一個 reset 方法。清單 4 顯示的就是這樣一個例子。

清單 4. 增加了 reset 方法的 Singleton 對象

?php
class Singleton
{
  private static $instance;
  protected function __construct() { }
  private final function __clone() {}
  public static function getInstance()
  {
    if ( !isset(self::$instance) ) {
      self::$instance = new Singleton;
    }
    return self::$instance;
  }
  public static function reset()
  {
    self::$instance = null;
  }
}

現(xiàn)在，我們可以在每次測試之前調(diào)用 reset 方法，保證我們在每次測試過程中都會先執(zhí)行 singleton 對象的初始化代碼。總之，在應(yīng)用程序中增加這個方法是很有用的，因為我們現(xiàn)在可以輕松地修改單一實例。

使用類構(gòu)造函數(shù)

進行單元測試的一個良好做法是只測試需要測試的代碼，避免創(chuàng)建不必要的對象和變量。您創(chuàng)建的每一個對象和變量都需要在測試之后刪除。這對于文件和數(shù)據(jù)庫表等 麻煩的項目來說成為一個問題，因為在這些情況下，如果您需要修改狀態(tài)，那么您必須更小心地在測試完成之后進行一些清理操作。堅持這一規(guī)則的最大障礙在于對 象本身的構(gòu)造函數(shù)，它執(zhí)行的所有操作都是與測試無關(guān)的。清單 5 就是這樣一個例子。

清單 5. 具有一個大 singleton 方法的類

?php
class MyClass
{
  protected $results;
  public function __construct()
  {
    $dbconn = new DatabaseConnection('localhost','user','password');
    $this->results = $dbconn->query('select name from mytable');
  }
  public function getFirstResult()
  {
    return $this->results[0];
  }
}

在這里，為了測試對象的 fdfdfd 方法，我們最終需要建立一個數(shù)據(jù)庫連接，給表添加一些記錄，然后在測試之后清除所有這些資源。如果測試 fdfdfd完全不需要這些東西，那么這個過程可能太過于復(fù)雜。因此，我們要修改 清單 6所示的構(gòu)造函數(shù)。

清單 6. 為忽略所有不必要的初始化邏輯而修改的類

?php
class MyClass
{
  protected $results;
  public function __construct($init = true)
  {
    if ( $init ) $this->init();
  }
  public function init()
  {
    $dbconn = new DatabaseConnection('localhost','user','password');
    $this->results = $dbconn->query('select name from mytable');
  }
  public function getFirstResult()
  {
    return $this->results[0];
  }
}

我們重構(gòu)了構(gòu)造函數(shù)中大量的代碼，將它們移到一個 init() 方法中，這個方法默認情況下仍然會被構(gòu)造函數(shù)調(diào)用，以避免破壞現(xiàn)有代碼的邏輯。然而，現(xiàn)在我們在測試過程中只能夠傳遞一個布爾值 false 給構(gòu)造函數(shù)，以避免調(diào)用 init()方法和所有不必要的初始化邏輯。類的這種重構(gòu)也會改進代碼，因為我們將初始化邏輯從對象的構(gòu)造函數(shù)分離出來了。

經(jīng)硬編碼的類依賴性

正如我們在前一節(jié)介紹的，造成測試困難的大量類設(shè)計問題都集中在初始化各種不需要測試的對象上。在前面，我們知道繁重的初始化邏 輯可能會給測試的編寫造成很大的負擔（特別是當測試完全不需要這些對象時），但是如果我們在測試的類方法中直接創(chuàng)建這些對象，又可能造成另一個問題。清單 7顯示的就是可能造成這個問題的示例代碼。

清單 7. 在一個方法中直接初始化另一個對象的類

?php
class MyUserClass
{
  public function getUserList()
  {
    $dbconn = new DatabaseConnection('localhost','user','password');
    $results = $dbconn->query('select name from user');
    sort($results);
    return $results;
  }
}

假設(shè)我們正在測試上面的 getUserList方法，但是我們的測試關(guān)注點是保證返回的 用戶清單是按字母順序正確排序的。在這種情況下，我們的問題不在于是否能夠從數(shù)據(jù)庫獲取這些記錄，因為我們想要測試的是我們是否能夠?qū)Ψ祷氐挠涗涍M行排 序。問題是，由于我們是在這個方法中直接實例化一個數(shù)據(jù)庫連接對象，所以我們需要執(zhí)行所有這些繁瑣的操作才能夠完成方法的測試。因此，我們要對方法進行修 改，使這個對象可以在中間插入，如 清單 8所示。

清單 8. 這個類有一個方法會直接實例化另一個對象，但是也提供了一種重寫的方法

?php
class MyUserClass
{
  public function getUserList($dbconn = null)
  {
    if ( !isset($dbconn) || !( $dbconn instanceOf DatabaseConnection ) ) {
      $dbconn = new DatabaseConnection('localhost','user','password');
    }
    $results = $dbconn->query('select name from user');
    sort($results);
    return $results;
  }
}

現(xiàn)在您可以直接傳入一個對象，它與預(yù)期數(shù)據(jù)庫連接對象相兼容，然后直接使用這個對象，而非創(chuàng)建一個新對象。您也可以傳 入一個模擬對象，也就是我們在一些調(diào)用方法中，用硬編碼的方式直接返回我們想要的值。在這里，我們可以模擬數(shù)據(jù)庫連接對象的查詢方法，這樣我們就只需要返 回結(jié)果，而不需要真正地去查詢數(shù)據(jù)庫。進行這樣的重構(gòu)也能夠改進這個方法，因為它允許您的應(yīng)用程序在需要時插入不同的數(shù)據(jù)庫連接，而不是只綁定一個指定的 默認數(shù)據(jù)庫連接。

可測試代碼的好處

顯然，編寫更具可測試性的代碼肯定能夠簡化 PHP 應(yīng)用程序的單元測試（正如您在本文展示的例子中所看到的），但是在這個過程中，它也能夠改進應(yīng)用程序的設(shè)計、模塊化和穩(wěn)定性。我們都曾經(jīng)看到過 “spaghetti” 代碼，它們在 PHP 應(yīng)用程序的一個主要流程中充斥了大量的業(yè)務(wù)和表現(xiàn)邏輯，這毫無疑問會給那些使用這個應(yīng)用程序的人造成嚴重的支持問題。在使代碼變得更具可測試性的過程中， 我們對前面一些有問題的代碼進行了重構(gòu)；這些代碼不僅設(shè)計上有問題，功能上也有問題。通過使這些函數(shù)和類的用途更廣泛，以及通過刪除硬編碼的依賴性，我們 使之更容易被應(yīng)用程序其他部分重用，我們提高了代碼的可重用性。此外，我們還將編寫不當?shù)拇a替換成更優(yōu)質(zhì)的代碼，從而簡化將來對代碼庫的支持。

結(jié)束語

在本文中，通過 PHP 應(yīng)用程序中一些典型的不可測試代碼示例，我們了解了如何改進 PHP 代碼的可測試性。我們還介紹了這些情況是如何出現(xiàn)在應(yīng)用程序中的，然后介紹了如何恰當?shù)匦迯?fù)這些問題代碼來便于進行測試。我們還了解了這些代碼的修改不僅 能夠提高代碼的可測試性，也能夠普遍改進代碼的質(zhì)量，以及提高重構(gòu)代碼的可重用性。

更多關(guān)于PHP相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《php面向?qū)ο蟪绦蛟O(shè)計入門教程》、《PHP數(shù)組(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運算與運算符用法總結(jié)》、《php字符串(string)用法總結(jié)》、《php+mysql數(shù)據(jù)庫操作入門教程》及《php常見數(shù)據(jù)庫操作技巧匯總》

希望本文所述對大家PHP程序設(shè)計有所幫助。