面向可維護性的構造技術
- OO設計原則：SOLID
-
- (SRP) The Single Responsibility Principle
- (OCP) The Open-Closed Principle
- (LSP) The Liskov Substitution Principle
- (ISP) The Interface Segregation Principle
- (DIP) The Dependency Inversion Principle
OO設計原則：SOLID
(SRP) The Single Responsibility Principle
SRP–單一責任原則
1.内容：不應有多于1個的原因使得一個類發生變化，即一個類，一個責任
2.舉例：
(OCP) The Open-Closed Principle
OCP–開放-封閉原則
1.對擴充性的開放：
這意味着子產品的行為可以被擴充。當應用程式的需求發生變化時，或者滿足新應用程式的需求時，我們可以使子產品以新的不同的方式運作。
2.對修改的封閉：
但子產品自身的代碼是不應被修改的，擴充子產品行為的一般途徑是修改子產品的内部實作，如果一個子產品不能被修改，那麼它通常被認為是具有固定的行為。
3.實作方式：
第一種：如果有多種類型的Server，那麼針對每一種新出現的Server，不得不修改Server類的内部具體實作。不推薦使用
第二種：通過構造一個抽象的Server類：AbstractServer，該抽象類中包含針對所有類型的Server都通用的代碼，進而實作了對修改的封閉；當出現新的Server類型時，隻需從該抽象類中派生出具體的子類ConcreteServer即可，進而支援了對擴充的開放。
4.舉例：
左邊：如果要修改m_type的值，則要修改内部代碼實作，破壞對修改的封閉。
右邊：如果要修改m_type的值，隻需要增加額外的類進行實作就可以，其他無關的類都不做改動，滿足OCP原則
(LSP) The Liskov Substitution Principle
LSP–Liskov 替換原則
子類型必須能夠替換其基類型，派生類必須能夠通過其基類的接口使用，用戶端無需了解二者之間的差異
(ISP) The Interface Segregation Principle
ISP–接口隔離原則
1.“ 胖”接口具有很多缺點：不夠聚合
胖接口可分解為多個小的接口，不同的接口向不同的用戶端提供服務，用戶端隻通路自己所需要的端口。
2.舉例：
這是一個不好的實作方式，RobotWorker不需要實作eat()方法，但由于接口中包含兩個方法，是以都要實作，不滿足ISP原則。
修改方式如下：
将上述兩個接口分離，實作類時隻實作需要功能的接口即可。
(DIP) The Dependency Inversion Principle
DIP–依賴轉置原則
1.抽象的子產品不應依賴于具體的子產品，具體應依賴于抽象
舉個例子：
下面的實作是通過接口而不是具體類實作的
2.實作方法：
不推薦的方法：上層client的代碼中直接嵌入了對下層具體實作機制的調用
滿足DIP的方法：上層client的代碼面向抽象接口程式設計，隔離對下層具體實作機制的直接接觸
再舉個例子：
delegation要通過接口實作，而不是具體子類