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

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

簡介

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

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

識別不可測試的代碼

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

依賴全局狀態的函數

全局變量在 PHP 應用程序中很方便。它們允許您在應用程序中初始化一些變量或對象，然后在應用程序的其他位置使用。然而，這種靈活性是有代價的，過度使用全局變量是不可測試代碼的一個通病。我們可以在 清單 1中看到這種情況。

清單 1. 依賴于全局狀態的函數

<?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);
}

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

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

<?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);
}

這樣做不僅使代碼變得更具可測試性，而且也使它不依賴于方法的全局變量。這使得我們能夠對代碼進行重構，不再使用全局變量。

無法重置的單一實例

單一實例指的是旨在讓應用程序中一次只存在一個實例的類。它們是應用程序中用于全局對象的一種常見模式，如數據庫連接和配置設置。它們通常被認為是應用程序的禁忌， 因為許多開發人員認為創建一個總是可用的對象用處不大，因此他們并不太注意這一點。這個問題主要源于單一實例的過度使用，因為它會造成大量不可擴展的所謂 god objects 的出現。但是從測試的角度看，最大的問題是它們通常是不可更改的。清單 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;
  }
}

您可以看到，當單一實例首次實例化之后，每次調用 getInstance() 方法實際上返回的都是同一個對象，它不會創建新的對象，如果我們對這個對象進行修改，那么就可能造成很嚴重的問題。最簡單的解決方案就是給對象增加一個 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;
  }
}

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

使用類構造函數

進行單元測試的一個良好做法是只測試需要測試的代碼，避免創建不必要的對象和變量。您創建的每一個對象和變量都需要在測試之后刪除。這對于文件和數據庫表等 麻煩的項目來說成為一個問題，因為在這些情況下，如果您需要修改狀態，那么您必須更小心地在測試完成之后進行一些清理操作。堅持這一規則的最大障礙在于對 象本身的構造函數，它執行的所有操作都是與測試無關的。清單 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 方法，我們最終需要建立一個數據庫連接，給表添加一些記錄，然后在測試之后清除所有這些資源。如果測試 fdfdfd完全不需要這些東西，那么這個過程可能太過于復雜。因此，我們要修改 清單 6所示的構造函數。

清單 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];
  }
}

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

經硬編碼的類依賴性

正如我們在前一節介紹的，造成測試困難的大量類設計問題都集中在初始化各種不需要測試的對象上。在前面，我們知道繁重的初始化邏 輯可能會給測試的編寫造成很大的負擔（特別是當測試完全不需要這些對象時），但是如果我們在測試的類方法中直接創建這些對象，又可能造成另一個問題。清單 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;
  }
}

假設我們正在測試上面的 getUserList方法，但是我們的測試關注點是保證返回的 用戶清單是按字母順序正確排序的。在這種情況下，我們的問題不在于是否能夠從數據庫獲取這些記錄，因為我們想要測試的是我們是否能夠對返回的記錄進行排 序。問題是，由于我們是在這個方法中直接實例化一個數據庫連接對象，所以我們需要執行所有這些繁瑣的操作才能夠完成方法的測試。因此，我們要對方法進行修 改，使這個對象可以在中間插入，如 清單 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;
  }
}

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

可測試代碼的好處

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

結束語

在本文中，通過 PHP 應用程序中一些典型的不可測試代碼示例，我們了解了如何改進 PHP 代碼的可測試性。我們還介紹了這些情況是如何出現在應用程序中的，然后介紹了如何恰當地修復這些問題代碼來便于進行測試。我們還了解了這些代碼的修改不僅 能夠提高代碼的可測試性，也能夠普遍改進代碼的質量，以及提高重構代碼的可重用性。

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