PHP代碼重構方法的示例分析

這篇文章給大家分享的是有關PHP代碼重構方法的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

具體如下：

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

簡介

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

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

識別不可測試的代碼

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

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

全局變量在 PHP 應用程序中很方便。它們允許您在應用程序中初始化一些變量或對象，然后在應用程序的其他位置使用。然而，這種靈活性是有代價的，過度使用全局變量是不可測試代碼的一個通病。我們可以在 清單 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ù)可接受的有效值。第二個問題更為嚴重， 那就是您無法修改后續(xù)測試的狀態(tài)并使它們的結果無效，您需要保證將全局狀態(tài)重置為測試運行之前的狀態(tài)。PHPUnit 有一些工具可以幫您備份全局變量并在測試運行后恢復它們的值，這些工具能夠幫助解決這個問題。然而，更好的方法是使測試類能夠直接給方法傳入這些全局變量的值。清單 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);
}

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

無法重置的單一實例

單一實例指的是旨在讓應用程序中一次只存在一個實例的類。它們是應用程序中用于全局對象的一種常見模式，如數(shù)據(jù)庫連接和配置設置。它們通常被認為是應用程序的禁忌， 因為許多開發(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;
  }
}

您可以看到，當單一實例首次實例化之后，每次調用 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)在，我們可以在每次測試之前調用 reset 方法，保證我們在每次測試過程中都會先執(zhí)行 singleton 對象的初始化代碼?？傊?，在應用程序中增加這個方法是很有用的，因為我們現(xiàn)在可以輕松地修改單一實例。

使用類構造函數(shù)

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

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

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

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

假設我們正在測試上面的 getUserList方法，但是我們的測試關注點是保證返回的 用戶清單是按字母順序正確排序的。在這種情況下，我們的問題不在于是否能夠從數(shù)據(jù)庫獲取這些記錄，因為我們想要測試的是我們是否能夠對返回的記錄進行排 序。問題是，由于我們是在這個方法中直接實例化一個數(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)在您可以直接傳入一個對象，它與預期數(shù)據(jù)庫連接對象相兼容，然后直接使用這個對象，而非創(chuàng)建一個新對象。您也可以傳 入一個模擬對象，也就是我們在一些調用方法中，用硬編碼的方式直接返回我們想要的值。在這里，我們可以模擬數(shù)據(jù)庫連接對象的查詢方法，這樣我們就只需要返 回結果，而不需要真正地去查詢數(shù)據(jù)庫。進行這樣的重構也能夠改進這個方法，因為它允許您的應用程序在需要時插入不同的數(shù)據(jù)庫連接，而不是只綁定一個指定的 默認數(shù)據(jù)庫連接。

可測試代碼的好處

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

感謝各位的閱讀！關于“PHP代碼重構方法的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！