物件導向設計原則：里氏替換原則，定義、解析
里氏替換原則（Liskov Substitution Principle）
定義
Subtypes must be substitutable for their base types.
-
子類別必須能取代父類別
里式替換原則是從 開放封閉原則 延伸出來的原則，若對開放封閉原則還不了解，建議先去瞭解開放封閉原則如何透過引入抽象來擴充程式碼的行為，再來學習里氏替換原則！
目的
讓開發人員確實地按照「介面」的定義進行實作，確保程式碼名符其實，避免發生無法預料的事情。
程式碼在編譯階段可以檢查出型別錯誤，卻不能檢查出開發人員犯傻。
因此里式替換原則要求開發人員確實地按照「介面」的定義進行實作，否則程式的行為將變得「不可預測」。換句話說，程式碼雖然可以“繞過”型別檢查使編譯成功，但有可能產生不可預知且不容易察覺的 Bugs。
解析
在開始講解之前，必須先引用 Uncle Bob 在 2017 年《Clean Architecture》對里氏替換原則的補充：
物件導向革命的最初幾年，里氏替換原則被用來指導「繼承的使用」。然而，多年以來里氏替換原則已經涉及到介面與實作，演變成了更廣泛的軟體設計原則。
引用這段是為了讓讀者知道，里氏替換原則不但適用於 繼承，也適用於 介面實作。
接下來將會講解為什麼里氏替換原則可以同時套用到 繼承 與 介面實作，以及里氏替換原則對物件導向開發的影響。
物件跟「抽象」與「介面」息息相關
「抽象」是人類處理複雜事物的方式。
人的大腦可以接收的訊息有限，因此在現實生活中，人類往往會對複雜的事物進行簡化，或將類似的事物歸納成同一類。對事物進行「抽象」雖然會忽略某些細節，但也讓人類更易於溝通、學習與管理。
舉例來說，在餐廳向大廚點一份炒高麗菜就利用「簡化」進行抽象，我們不會告訴大廚怎麼切菜、火要多大以及料理的順序；學校常見的告示牌“教室內不能喝飲料”也是「歸納」進行抽象，不可能將綠茶、奶茶、果汁、啤酒 …等等全部寫到告示牌上。
舉例來說，在餐廳向大廚點一份炒高麗菜就利用「簡化」進行抽象，我們不會告訴大廚怎麼切菜、火要多大以及料理的順序；學校常見的告示牌“教室內不能喝飲料”也是「歸納」進行抽象，不可能將綠茶、奶茶、果汁、啤酒 …等等全部寫到告示牌上。
開發人員也會透過物件「封裝」的功能對程式碼進行抽象，把複雜的流程或業務規則隱藏到物件的內部。當程式碼被抽象成為物件後，就可以透過「外部視角」和「內部視角」來觀察一個物件：從「外部視角」觀察物件時，只能看見程式碼被簡化成一系列的 抽象行為。從內部觀察物件時，則可以看見每個行為的實作內容。
在外部視角中，只能得到物件公開（Public）的資訊，包含：公開屬性、常數、方法簽名（Signature，指方法名稱與其參數）。我們會將這些物件公開的資訊統稱為「介面」，所以很多物件導向設計（OOAD）的書籍提到介面時，可能同時是在講 Interface、類別 和 抽象類別。
開發人員常常透過「介面」描述一個業務邏輯的基本特徵，包含要實現的功能目標與涉及範圍。並忽略介面的實際結構與行為實作內容。
「繼承」是為了共用父類別的介面
為了促使程式碼遵循 開放封閉原則，開發人員可以透過物件導向的繼承技術，繼承父類別的「介面」來擴充業務規則的邏輯。
不論是繼承或是介面，目的都是利用多型的特性來擴充業務規則的邏輯。這也是為什麼里氏替換原則可以同時適用於繼承與介面實作。
「繼承」不為了共用父類別的程式碼
若只是想要共用父類別的邏輯，應該使用組合，而不是使用繼承。雖然沒有人會限制開發人員隨意地使用繼承，但如果使用繼承的目的不是為了「多型」，不但沒有讓繼承功能派上用場，還會迫使子類別公開父類別的「介面」。
契約式設計（Design by Contract）
里氏替換原則延伸出契約式設計，契約式設計用了三個條件來規範開發人員應該如何遵循「介面」的實作：
- 前置條件（pre-conditions）
實作「介面」的實體物件，必須包含並保留所有「介面」的公開資訊。確保依賴「介面」的程式可以調用「介面」提供的功能。只有前置條件達成時，程式碼才會執行後置條件的邏輯。 - 後置條件（post-conditions）
實作「介面」的實體物件，在執行完「介面」提供的功能後，必須回傳「介面」指定的回傳型別（Return Type）。約束開發人員要按照介面的定義實作功能。 - 不變性（invariants）
若 前置條件 或 後置條件 任一項條件沒有達成，程式碼就會報錯。
這三個條件就是物件導向語言中的 Interface 的限制條件，因此 Interface 也經常被稱作契約（Contract）。
範例
接下來利用 系統通知信件 示範違反與符合里氏替換原則的案例。
某系統有通知信件的功能，可以因應多種情境寄送對應的通知信件內容：
class EmailSender
{
private $mail;
private $emails;
/**
* 加入信件
*
* @param string $address
* @param EmailMaker $emailMaker 用於建立信件內容
*/
public function addEmail($address, EmailMaker $emailMaker)
{
$email = [
'address' => $address,
'emailHTML' => $emailMaker->makeEmailHTML(),
];
array_push($this->emails, $email);
}
/**
* 寄送信件
*/
public function send()
{
foreach ($this->emails as $email) {
$this->mail->setAddress($email['address']);
$this->mail->setBody($email['emailHTML']);
$this->mail->Send();
}
}
}
在這個系統中，所有情境的通知信件都是透過
EmailSender 來寄送信件。從上面程式碼中可以發現，開發人員希望透過 多型 來建立不同情境的信件樣板，因此在 addEmail 方法中引入一個專門用來建立信件樣板的介面 EmailMaker：interface EmailMaker
{
/**
* 建立信件 HTML 內容
* @return string
*/
public function makeEmailHTML(): string;
}
到目前為止，
EmailSender 已經建立起 開放封閉原則 的 Plugin 架構，開發人員只需要新增實作 EmailMaker 介面的類別，就能替系統建立全新的通知信件種類（開放擴充）。完全不需要更改 EmailSender 的程式碼（關閉修改）。
里氏替換原則就像一個審查機制，監督開發人員在實作 開放封閉原則 Plugin 架構的介面（EmailMaker）時，讓程式碼的行為符合介面的定義。目的是確保開放封閉原則的核心業務邏輯（EmailSender）可以安全地使用 Plugin 來擴充邏輯。
違反里氏替換原則
/**
* 上課遲到通知信件 HTML 產生器
*/
class LateForClassEmailHTML implements EmailMaker
{
public function __construct($studentId, $classInfo)
{
$this->studentId = $studentId;
$this->classInfo = $classInfo;
}
/**
* 建立信件 HTML 內容
* @return string
*/
public function makeEmailHTML(): string
{
// 建立 上課遲到通知信件 HTML 樣板
$this->template = new Template('emails');
$template = $this->template->load('emails/template/lateForClass', $this->classInfo);
// 扣除學生課程總成績
$studentCourse = StudentCourse::where(['studentId' => $this->studentId, 'classId' => $this->classInfo['classId']);
$studentCourse->totalScore = $studentCourse->totalScore - 1;
$studentCourse->save();
return $template;
}
}
在這個案例中，需求為「若學生上課遲到就寄送遲到通知信件，並扣除學生的課程總成績 1 分」。
開發人員新增
LateForClassEmailHTML 類別並實作 EmailMaker 介面替系統新增「學生上課遲到」通知信件內容。
但是上面的範例違反了里氏替換原則，因為
EmailMaker 介面明確定義 makeEmailHTML 的目的是「建立信件 HTML 內容」，但開發人員卻將「扣除學生的課程總成績」邏輯寫在 makeEmailHTML 函式中。雖然程式碼仍然會通過型別檢查（Type Hint），但卻會增加維護系統的困難度。
這些「不符合介面定義的程式碼」被放在不合理的地方，就會成為系統的技術債，開發人員會需要更多時間找碴程式碼，例如，從 Controller 層根本看不出「扣除學生的課程總成績」的邏輯在哪裡被執行：
// Controller 層
public function StudentLateForClass {
/** ...省略 */
$emailMaker = new LateForClassEmailHTML($student->id, $classInfo);
$emailSender = new EmailSender();
$emailSender->addEmail($student->email, $emailMaker);
$emailSender->send();
}
符合里氏替換原則
開發人員在實作「介面」的時候，應該完全按照介面的「定義」來撰寫功能，而且要不多也不少：
/**
* 上課遲到通知信件 HTML 產生器
*/
class LateForClassEmailHTML implements EmailMaker
{
public function __construct($studentId, $classInfo)
{
$this->classInfo = $classInfo;
}
/**
* 建立信件 HTML 內容
* @return string
*/
public function makeEmailHTML(): string
{
// 建立 上課遲到通知信件 HTML 樣板
$this->template = new Template('emails');
$template = $this->template->load('emails/template/lateForClass', $this->classInfo);
return $template;
}
}
「介面」不只是定義了一個類別的職責，也畫出類別的邊界。如果程式碼不符合「介面」所定義的範圍，就要將不符合定義的程式碼從介面中搬移到適合的地方：
// Controller 層
public function StudentLateForClass {
/** ...省略 */
$emailMaker = new LateForClassEmailHTML($student->id, $classInfo);
$emailSender = new EmailSender();
$emailSender->addEmail($student->email, $emailMaker);
$emailSender->send();
// 扣除學生的課程總成績
$studentCourse = StudentCourse::where(['studentId' => $this->studentId, 'classId' => $this->classInfo['classId']);
$studentCourse->totalScore = $studentCourse->totalScore - 1;
$studentCourse->save();
}
結論
開放封閉原則必須透過 統一的抽象介面 來擴充核心業務規則的邏輯，因此在設計模式中作者們提出 “Program to an interface, not an implementation.”，將需求的問題域定義成抽象介面，系統才能安全地的擴展程式碼。搭配里氏替換原則對開發人員的限制，確保程式碼的行為符合「介面」的定義與預期，讓開放封閉原則可以信任實作「介面」的程式碼，最終讓系統可以用「增量式開發」的方式進行迭代釋出。
留言
張貼留言