Laravel深入學習10 黎克特制替換原則

別擔心，黎克特制替換原則實際上比他的名字好理解。他是指任何在任何接受抽象化類的地方其實現也被接受。通俗的講，類中使用介面實現的地方，不需要修改**對於任意的介面實現類都將能使用。

黎克特制替換原則

該原則表示，程式中對於例項化物件的子型別，不需要修改**，可以直接進行替換。

我們繼續拿orderprocessor舉例來闡述該原則，看下這個方法：

public function process(order $order)

在order驗證之後，我們使用orderrepositoryinte***ce介面實現類來記錄訂單日誌。我們假定，當訂單處理未成熟時，我們將所有的訂單以csv格式記錄到系統中。我們的額orderrepositoryinte***ce介面實現類為csvorderrepository。當業務繼續發展，我們想使用關係型資料庫記錄訂單。下面，我們看下一種可能的介面實現：

class databaseorderrepository implements orderrepositoryinte***ce 
public function logorder(order $order)
}

現在，讓我們檢驗下如何將不得不去使用此實現：

public function process(order $order)
$this->repository->logorder($order);
}

注意，在訂單處理類中，我們強制檢測了orderrepositoryinte***ce是否為乙個資料庫的實現方式。如果是，繼續資料庫的連線。在小型應用中還算是小問題，但是，如果在很多其他類中orderrepositoryinte***ce被使用到時怎麼辦？我們就只能在所有地方去新增這段「引導」**。這樣的**維護讓人頭痛，還會**潛在的bug，如果有乙個地方忘記修改，就瞎了。

上述例項已違背黎克特制替換原則。在不修改connect方法的情況下我們無法注入介面的實現類。既然發現了問題，那就去修復他們吧。這裡是乙個新的databaseorderrepository實現類：

class databaseorderrepository implements orderrepositoryinte***ce 
public function connect()
public function logorder(order $order)
}

現在在databaseorderrepository中實現了資料庫連線的管理，我們就可以從orderprocessor中移除那段「引導」**了：

public function process(order $order)

如此改變，我們就可以在orderprocessor中隨意使用csvorderrepository或者databaseorderrepository了。我們的**遵循了黎克特制替換原則。很多建築學上的概念都被討論成一種「認知」。特別的，對於每乙個類，都有其自己的「語境」，他周邊的**在其依賴環境下幫助類來完成特定的工作。當你讓架構朝著健壯方向發展的時候，這種類的設計「認知」將是一種持久重要的主題。

小心漏洞

你也許注意到了本原則和上章中提到的迴避「抽象漏洞」類似。我們的資料庫獲取部分就是破壞黎克特制替換的點，在你以後的編碼中一定要對這種編碼留心！

Laravel深入學習10 黎克特制替換原則

Laravel深入學習12 依賴倒置原則

UIApplication深入學習

深入學習CSS

Laravel深入學習10 黎克特制替換原則

Laravel深入學習12 依賴倒置原則

UIApplication深入學習

深入學習CSS

相關推薦