《PHP設計模式介紹》第十章規范模式

2024-05-04 21:51:48

字體：大中小

來源：轉載

供稿：網友

在一個應用軟件的成型過程中，一些意想不到的商業邏輯到處出現。比如，基于價格的考慮，這個任務必須減少項目；而那個任務也因為銷售稅而必須選擇合適的比率；而其它的任務也必須因為其他的特別條件而終止。一些商業規則是簡單的，只需要不到一兩個布爾比較關系就夠了，然而它的規則可能需要費時的估計，需要查詢數據庫或者用戶輸入數據來引導。

通過書寫代碼可以把抽象（比如一條商業規則）轉化為具體可見的東西。但是抽象物（比如購物方式，稅率，或者計算海運費等等）都有其進化的方式，而且這些改變很容易難倒一個不幸運的開發人員。為了保證安全可靠——到目前為止你在這本書所看到的——盡可能的分離封裝那些容易改變的模塊是個很完美的想法。而且，這的確也一個明智的應對商業規則的策略。

問題描述

有沒有明確的方式來封裝商業邏輯呢？有沒有一個容易改寫和重用的技術呢？

解決方案

規范模式是為驗證和選擇而開發的：

確認一個特殊的對象是否滿足一定的標準

從集合中選擇出滿足給定標準的元素。

規范模式能讓你有效的組織這些標準，并在你的應用程序中靈活的使用他們。

代碼重構技術已經激發你的興趣，你決定使用它來提升代碼的清晰度和重用性。規范模式通過系統化進一步的深化了這一步，它系統把這個結構分解成一個個單獨的對象，這些對象能夠很方便的插入到你的應用程序的合適地方。很多情況下，在你的應用程序里，規范對象是參數化的，而且經常被組合在一起來構建復雜的合乎邏輯的表達式。

相關知識

Eric Evans 和 Martin Fowler 發表過一篇關于規范模型的文章，地址是：

http://www.martinfowler.com/apsupp/spec.pdf

這個模式在Eric Evans的書本《動態驅動設計》(“Domain Driven Design”)的第224到273頁有詳細的介紹。

為了合理的全面覆蓋這個模式，這章被組織成合乎邏輯的三部分。第一部分通過一個純粹的實例來說明基本的模式概念。（Evans 和 Fowler 把這個稱為為“硬編碼規范Hard Coded Specification”）。接下來的部分演示了如何構建一個參數化規范模型，它提供了一個更加動態和靈活的框架來實現規范模式（或者因此而稱為“參數化規范”）的重用。最后一部分，我們開發了一個“方案工廠”（Policy Factory）,它把許多規范對象集中成一個易于使用的包（package）。

Traveling to Warm Destinations(到溫暖的目的地去旅行)

最近，我和我的家人計劃去度一個假期，我的妻子想去一個“溫暖的地方”。雖然有無數旅行相關的站點，但是在我們訪問過的站點中沒有一個站點能夠為每一個目的地提供詳細的天氣信息。沒辦法，我們不得不轉到weather.com然后開始搜索，這是十分的不方便的。現在讓我們來改變這種情況，為一個假定的旅行站點增加一個天氣搜索功能。在這里我們是用規范模式這個指南來引導你編碼，從而比較旅行者期望的最低溫度和許多目的地的平均溫度

首先，我們創建一些非常簡單的對象。第一個是旅行者（a Traveler），它存儲了首選的最低溫度。

// PHP5
class Traveler {
public $min_temp;
}

接下來我們創建一個對象來表示目的地（Destination）。由于平均溫度是一個關鍵的標準，目的地的構建函數（__constructor）應該得到一個十二維的數組，該數組的每一個值對應一年里面每個月的平均溫度。

class Destination {
protected $avg_temps;
public function __construct($avg_temps) {
$this->avg_temps = $avg_temps;
}
}

目的地（Destination）同樣也還要一個方法，通過調用這個方法能夠得到這個目的地在指定月份的平均溫度。

class Destination {
//...
public function getAvgTempByMonth($month) {
$key = (int)$month - 1;
if (array_key_exists($key, $this->avg_temps)) {
return $this->avg_temps[$key];
}
}
}

最后，一次旅行（類Trip）就由一個旅行者（類Traveler），一個目的地（類Destination）和一個日期（a Date）聯合組成。

class Trip {
public $date;
public $traveler;
public $destination;
}

給出上面這些對象，你就可以通過Trip：：date得到旅行的月份，并且你能夠比較目的地的月平均溫度和旅行者期望的最低溫度。（這個比較可能不是特別的復雜，但是你還是需要你自己親自去實現）

讓我們看看如何用規范模式實現“溫暖目的地”的商業邏輯，并且看看如何應用這個模式來驗證每一個目的地并選擇出所有合適的目的地。

樣本代碼

規范模式的核心是一個帶有IsSatisfiedBy()方法的對象，IsSatisfiedBy()方法接收一個變量來評估并且返回一個基于規范標準的布爾值。

“目的地是足夠溫暖的”的標準可能就是：

class TripRequiredTemperatureSpecification {
public function isSatisfiedBy($trip) {
$trip_temp = $trip->destination->getAvgTempByMonth(
date(‘m’, $trip->date));
return ($trip_temp >= $trip->traveler->min_temp);
}
}

下面是一些測試，用來檢驗這個規范是如何工作的。

一個最初的個體測試事例提供了一些目的地來一起工作：

class TripSpecificationTestCase extends UnitTestCase {
protected $destinations = array();
function setup() {
$this->destinations = array(
‘Toronto’ => new Destination(
array(24, 25, 33, 43, 54, 63, 69, 69, 61, 50, 41, 29))
,’Cancun’ => new Destination(
array(74, 75, 78, 80, 82, 84, 84, 84, 83, 81, 78, 76))
);
}
}

（構造這些目的地（Destination）需要在實例化的時候輸入一個包含每月平均溫度的數組。做為一個美國的作者，在這些例子中我選擇了華氏溫度。對應的，Vicki期望的華氏溫度70度等價于攝氏溫度21度）

下一個測試構建了一個旅行者（Traveler），并且設置了它的首選最低溫度和旅行日期同時也選擇了一個目的地。這最初的組合“最低溫度70度（華氏溫度），目的地多倫多（Toronto），日期二月中旬”會和期望的一樣，是不能通過的。

class TripSpecificationTestCase extends UnitTestCase {
// ...
function TestTripTooCold() {
$vicki = new Traveler;
$vicki->min_temp = 70;
$toronto = $this->destinations[‘Toronto’];
$trip = new Trip;
$trip->traveler = $vicki;
$trip->destination = $toronto;
$trip->date = mktime(0,0,0,2,11,2005);
$warm_enough_check = new TripRequiredTemperatureSpecification;
$this->assertFalse($warm_enough_check->isSatisfiedBy($trip));
}
}

但是，接下來的這個組合“70度，二月中旬，Cancun ”就會通過，和我們期望的一樣。

class TripSpecificationTestCase extends UnitTestCase {
// ...
function TestTripWarmEnough() {
$vicki = new Traveler;
$vicki->min_temp = 70;
$cancun = $this->destinations[‘Cancun’];
$trip = new Trip;
$trip->traveler = $vicki;
$trip->destination = $cancun;
$trip->date = mktime(0,0,0,2,11,2005);
$warm_enough_check = new TripRequiredTemperatureSpecification;
$this->assertTrue($warm_enough_check->isSatisfiedBy($trip));
}
}