淺談面向物件的六大設計原則
摘要：
image.png
原則一、單一職責原則（Single Responsibility Principle，簡稱SRP ）
定義：應該有且僅有一個原因引起類的變更。
一個類只負責一項職責，如果發生變更時，可以考慮將一個類拆分成兩個類，或者在一個...
image.png
原則一、單一職責原則（Single Responsibility Principle，簡稱SRP ）
定義：應該有且僅有一個原因引起類的變更。
一個類只負責一項職責，如果發生變更時，可以考慮將一個類拆分成兩個類，或者在一個類中新增新的方法。
在真實的開發中，不僅僅是類、函式和介面也要遵循單一職責原則。即：一個函式負責一個功能。如果一個函式裡面有不同的功能，則需要將不同的功能的函式分離出去。
優點：
- 類的複雜性降低，實現什麼職責都有清晰明確的定義。
- 類的可讀性提高，複雜性減低。
如果介面或者函式的單一職責做得好，一個介面或者函式的修改只對相應的類有影響，對其他介面或者函式無影響，這對系統的擴充套件性、維護性都有非常大的幫助。
例如，需求上指出用一個類描述食肉和食草動物：
//================== Animal.h ================== @interface Animal : NSObject - (void)eatWithAnimalName:(NSString *)animalName; @end
執行結果：
2018-10-27 17:55:25.775317+0800 DesignPatterns[54087:24701786] 狼 吃肉 2018-10-27 17:55:25.775689+0800 DesignPatterns[54087:24701786] 豹 吃肉 2018-10-27 17:55:25.775721+0800 DesignPatterns[54087:24701786] 虎 吃肉
上線後，發現問題了，並不是所有的動物都是吃肉的，比如羊就是吃草的。修改時如果遵循單一職責原則，需要將 Animal 類細分為食草動物類 Herbivore ，食肉動物 Carnivore ，程式碼如下：
//================== Herbivore.h ================== @interface Herbivore : Animal @end @implementation Herbivore - (void)eatWithAnimalName:(NSString *)animalName { NSLog(@"%@ 吃草", animalName); } @end //================== Carnivore.h ================== @interface Carnivore : Animal @end @implementation Carnivore - (void)eatWithAnimalName:(NSString *)animalName { NSLog(@"%@ 吃肉", animalName); } @end //================== main 函式 ================== Animal *carnivore = [Carnivore new]; [carnivore eatWithAnimalName:@"狼"]; [carnivore eatWithAnimalName:@"豹"]; [carnivore eatWithAnimalName:@"虎"]; NSLog(@"\n"); Animal *herbivore = [Herbivore new]; [herbivore eatWithAnimalName:@"羊"];
在子類裡面重寫父類的 eatWithAnimalName 函式，執行結果：
2018-10-27 18:04:49.189722+0800 DesignPatterns[54422:24725132] 狼 吃肉 2018-10-27 18:04:49.190450+0800 DesignPatterns[54422:24725132] 豹 吃肉 2018-10-27 18:04:49.190482+0800 DesignPatterns[54422:24725132] 虎 吃肉 2018-10-27 18:04:49.190498+0800 DesignPatterns[54422:24725132] 2018-10-27 18:04:49.190530+0800 DesignPatterns[54422:24725132] 羊 吃草
這樣一來，不僅僅在此次新需求中滿足了單一職責原則，以後如果還要增加食肉動物和食草動物的其他功能，就可以直接在這兩個類裡面新增即可。但是，有一點，修改花銷是很大的，除了將原來的類分解之外，還需要修改 main 函式 。而直接修改類 Animal 來達成目的雖然違背了單一職責原則，但花銷卻小的多，程式碼如下：
//================== Animal.h ================== @interface Animal : NSObject - (void)eatWithAnimalName:(NSString *)animalName; @end @implementation Animal - (void)eatWithAnimalName:(NSString *)animalName { if ([@"羊" isEqualToString:animalName]) { NSLog(@"%@ 吃草", animalName); } else { NSLog(@"%@ 吃肉", animalName); } } @end //================== main 函式 ================== Animal *animal = [Animal new]; [animal eatWithAnimalName:@"狼"]; [animal eatWithAnimalName:@"豹"]; [animal eatWithAnimalName:@"虎"]; [animal eatWithAnimalName:@"羊"];
執行結果：
2018-10-27 18:16:10.910397+0800 DesignPatterns[54677:24751636] 狼 吃肉 2018-10-27 18:16:10.911105+0800 DesignPatterns[54677:24751636] 豹 吃肉 2018-10-27 18:16:10.911138+0800 DesignPatterns[54677:24751636] 虎 吃肉 2018-10-27 18:16:10.911160+0800 DesignPatterns[54677:24751636] 羊 吃草
可以看到，這種修改方式要簡單的多。
但是卻存在著隱患： 有一天需求上增加牛和馬也需要吃草，則又需要修改 Animal 類的 eatWithAnimalName 函式，而對原有程式碼的修改會對呼叫狼、豹和虎吃肉等功能帶來風險，也許某一天你會發現執行結果變為虎也吃草了。 這種修改方式直接在程式碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。還有一種修改方式：
//================== Animal.h ================== @interface Animal : NSObject /** *吃草 */ - (void)eatGrassWithAnimalName:(NSString *)animalName; /** *吃肉 */ - (void)eatMeatWithAnimalName:(NSString *)animalName; @end @implementation Animal - (void)eatGrassWithAnimalName:(NSString *)animalName { NSLog(@"%@ 吃草", animalName); } - (void)eatMeatWithAnimalName:(NSString *)animalName { NSLog(@"%@ 吃肉", animalName); } @end //================== main 函式 ================== Animal *animal = [Animal new]; [animal eatMeatWithAnimalName:@"狼"]; [animal eatMeatWithAnimalName:@"豹"]; [animal eatMeatWithAnimalName:@"虎"]; [animal eatGrassWithAnimalName:@"羊"];
執行結果：
2018-10-27 18:31:30.321473+0800 DesignPatterns[55048:24787008] 狼 吃肉 2018-10-27 18:31:30.321884+0800 DesignPatterns[55048:24787008] 豹 吃肉 2018-10-27 18:31:30.321922+0800 DesignPatterns[55048:24787008] 虎 吃肉 2018-10-27 18:31:30.321939+0800 DesignPatterns[55048:24787008] 羊 吃草
通過執行結果可以看到，這種修改方式沒有改動原來的函式，而是在類中新加了一個函式，這樣雖然也違背了 類單一職責原則 ，但在函式級別上卻是符合單一職責原則的，因為它並沒有動原來函式的程式碼。
在實際的開發應用中，有很多複雜的場景，怎麼設計一個類或者一個函式，讓應用程式更加靈活，是更多程式員們值得思考的，需要結合特定的需求場景，有可能有些類裡面有很多的功能，但是切記不要將不屬於這個類本身的功能也強加進來，這樣不僅帶來不必要的維護成本，也違反了 單一職責的設計原則 。
原則二、里氏替換原則（Liskov Substitution Principle，簡稱LSP）
定義：如果對一個型別為 T1 的物件 o1 ，都有型別為 T2 的物件 o2 ，使得以 T1 定義的所有程式 P 在所有的物件 o1 都替換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。有點拗口，通俗點講， 只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者不需要知道是父類還是子類。但是，反過來就不行了，有子類出現的地方，父類未必就能適應 。
面向物件的語言的三大特點是繼承、封裝、多型，里氏替換原則就是依賴於繼承、多型這兩大特性。當使用繼承時，遵循里氏替換原則。但是使用繼承會給程式帶來侵入性，程式的可移植性降低，增加了物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能會產生影響。子類可以擴充套件父類的功能，但不能改變父類原有的功能。
注意：
- 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。
- 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
比如，需要完成一個兩數相加的功能：
//================== A.h ================== @interface A : NSObject /** 加法 @param a @param b @return 相加之後的和 */ - (NSInteger)addition:(NSInteger)a b:(NSInteger)b; @end //================== main 函式 ================== A *a = [[A alloc] init]; NSLog(@"100+50=%ld", [a addition:100 b:50]); NSLog(@"100+80=%ld", [a addition:100 b:80]);
執行結果如下，
2018-11-01 22:53:23.549358+0800 DesignPatterns[18063:363232] 100+50=150 2018-11-01 22:53:23.549586+0800 DesignPatterns[18063:363232] 100+80=180
接著，需求上需要增加一個新的功能，完成兩數相加，然後再與 100 求差，由類 B 來負責。即類 B 需要完成兩個功能：
由於類 A 已經實現了加法功能，所以 B 繼承 A 之後，只需要完成減法功能就可以了，但是在類 B 中不小心重寫了父類 A 的減法功能，如下：
//================== B.h ================== @interface B : A /** 加法 @param a @param b @return 相加之後的和 */ - (NSInteger)addition:(NSInteger)a b:(NSInteger)b; /** 減法 @param a @param b @return 相加之後的和 */ - (NSInteger)subtraction:(NSInteger)a b:(NSInteger)b; @end //================== main 函式 ================== B *b = [[B alloc] init]; NSInteger sub = [b addition:100 b:50]; NSInteger difference = [b subtraction:sub b:100]; NSLog(@"100+50=%ld", sub); NSLog(@"100+100+50=%ld", difference);
執行結果如下，
2018-11-01 23:15:06.530080+0800 DesignPatterns[18363:375940] 100+50=5000 2018-11-01 23:15:06.530758+0800 DesignPatterns[18363:375940] 100+100+50=4900
發現原本執行正常的相減功能發生了錯誤，原因就是類 B 在給方法起名時無意中重寫了父類的方法，造成所有執行相減功能的程式碼全部呼叫了類 B 重寫後的方法，造成原本執行正常的功能出現了錯誤。如果按照“里氏替換原則”， 只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者不需要知道是父類還是子類 ，是不成立的。
在平時的日常開發中，通常會通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可複用性會比較差，特別是運用多型比較頻繁時，程式執行出錯的機率非常大。
原則三、依賴倒置原則（Dependence Inversion Principle，簡稱DIP）
依賴倒置原則的核心思想是面向介面程式設計。
定義：模組間的依賴通過抽象發生，高層模組和低層模組之間不應該發生直接的依賴關係，二者都應該是通過介面或抽象類產生的；即依賴抽象，而不依賴具體的實現。
例如：類 A 直接依賴類 B ，假如要將類 A 改為依賴類 C ，則必須通過修改類 A 的程式碼來達成。比如在這種場景下，業務邏輯層類 A 相對於資料層類 B 是高層模組，因為業務邏輯層需要呼叫資料層去連線資料庫，如果業務邏輯層類 A 依賴資料層類 B 的話，那麼將來需求變更，需要把舊的資料層類 B 修改為新的資料層類 C ，就必須通過修改類 A ，這樣就會給應用程式帶來不必要的風險。
解決方案：將類 A 修改為依賴介面 I ，類 B 和類 C 各自實現介面 I ，類 A 通過介面 I 間接與類 B 或者類 C 發生聯絡，則會大大降低修改類 A 的機率。要做到可擴充套件高複用，儘量不要讓業務邏輯層依賴資料層，可以在資料層抽象出一個介面，讓業務邏輯層依賴於這個抽象介面。
比如：母親給孩子講故事，只要給她一本書，她就可以照著書給孩子講故事了。
//================== Book.h ================== @interface Book : NSObject /** 故事內容 */ - (void)theStoryContent; @end //================== Mother.h ================== @class Book; @interface Mother : NSObject /** 講故事 */ - (void)tellStory:(Book *)book; @end //================== main 函式 ================== Mother *mother = [Mother new]; Book *book = [Book new]; [mother tellStory:book];
執行結果如下，
2018-11-09 14:52:08.759154+0800 DesignPatterns[6135:458778] 媽媽開始講故事 2018-11-09 14:52:08.759365+0800 DesignPatterns[6135:458778] 很久很久以前有一個阿拉伯的故事……
將來有一天，需求變更成，增加讓母親講一下報紙上的故事的功能，如下：
//================== Newspaper.h ================== @interface Newspaper : NSObject /** 報紙內容 */ - (void)theStoryContent; @end
如果將 Newspaper 類替換 Book 類，發現母親看不懂報紙上的故事，必須要修改 Mother 類裡面的 tellStory 方法才能看不懂報紙上的故事。假如以後需求換成雜誌呢？換成網頁呢？還要不斷地修改 Mother 類，這顯然不是好的設計，高層模組都依賴了低層模組的改動，因此上述設計不符合依賴倒置原則。 Mother 類與 Book 類之間的耦合性太高了，必須降低他們之間的耦合度才行。
解決方案，將母親講故事的方法抽象一個介面或者 Protocol ，讓 Mother 類不再依賴 Newspaper 和 Book 類具體實現，而是依賴抽象出來的介面或者 Protocol 。並且 Newspaper 和 Book 類也都依賴這個抽象出來的介面或者 Protocol ，通過實現介面或者 Protocol 來做自己的事情。
//================== IReaderProtocol.h ================== @protocol IReaderProtocol <NSObject> /** 故事內容 */ - (void)theStoryContent; @end
Mother 類與介面 IReader 發生依賴關係，而 Book 和 Newspaper 都屬於讀物的範疇，他們各自都去實現 IReader 介面，這樣就符合依賴倒置原則了，程式碼修改為：
//================== Book.h ================== @interface Book : NSObject <IReaderProtocol> @end //================== Newspaper.h ================== @interface Newspaper : NSObject <IReaderProtocol> @end //================== IReaderProtocol.h ================== @protocol IReaderProtocol <NSObject> /** 故事內容 */ - (void)theStoryContent; @end //================== Mother.h ================== @interface Mother : NSObject /** 講故事 */ - (void)tellStory:(NSObject<IReaderProtocol> *)reading; @end @implementation Mother - (void)tellStory:(NSObject<IReaderProtocol> *)reading { NSLog(@"媽媽開始講故事"); if ([reading respondsToSelector:@selector(theStoryContent)]) { [reading theStoryContent]; } } @end //================== main 函式 ================== Mother *mother = [Mother new]; Book *book = [Book new]; Newspaper *newspaper = [Newspaper new]; [mother tellStory:book]; [mother tellStory:newspaper];
執行結果如下，
2018-11-09 15:28:01.182603+0800 DesignPatterns[7055:532924] 媽媽開始講故事 2018-11-09 15:28:01.182879+0800 DesignPatterns[7055:532924] 很久很久以前有一個阿拉伯的故事…… 2018-11-09 15:28:01.182916+0800 DesignPatterns[7055:532924] 媽媽開始講故事 2018-11-09 15:28:01.182955+0800 DesignPatterns[7055:532924] 雄鹿終結勇士八連勝……
這樣修改後，無論以後怎樣擴充套件 main 函式，都不需要再修改 Mother 類了。這裡只是舉了一個比較簡單的例子，在實際的專案開發中，儘可能的採用“低耦合，高內聚”的原則， 採用依賴倒置原則給多人並行開發帶來了極大的便利 ，無論是面向過程程式設計還是面向物件程式設計，只有使各個模組之間的耦合儘量的低，才能提高程式碼的複用率。所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統的穩定性，降低修改程式造成的風險。
原則四、介面隔離原則（Interface Segregation Principle,簡稱ISP）
定義：客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。
Class 'ClassB' does not conform to protocol 'InterfaceH' Class 'ClassD' does not conform to protocol 'InterfaceH'
注意：在 Objective-C 中的協議可以通過 @optional 關鍵字宣告不需要必須實現的方法，這個只是 Objective-C 的一個特性，可以消除在 ClassB 和 ClassD 中沒有實現 InterfaceH 的 protocol 協議。
比如，類 A 依賴介面 H 中的方法1、方法2、方法5，類 B 是對類 A 依賴的實現。類 C 依賴介面 H 中的方法3、方法4、方法5，類 D 是對類 C 依賴的實現。對於類 B 和類 D 來說，雖然他們都存在著用不到的方法，但由於實現了介面 H，因為介面 H 對於類 A 和類 C 來說不是最小介面，所以也必須要實現這些用不到的方法。
//================== InterfaceH.h ================== @protocol InterfaceH <NSObject> - (void)method1; - (void)method2; - (void)method3; - (void)method4; - (void)method5; @end //================== ClassB.h ================== @interface ClassB : NSObject <InterfaceH> @end @implementation ClassB - (void)method1 { NSLog(@"類 B 實現介面 H 的方法1"); } - (void)method2 { NSLog(@"類 B 實現介面 H 的方法2"); } - (void)method3 { //not necessarily } - (void)method4 { //not necessarily } - (void)method5 { NSLog(@"類 B 實現介面 H 的方法5"); } @end //================== ClassA.h ================== @interface ClassA : NSObject - (void)depend:(NSObject<InterfaceH> *)classB; @end @implementation ClassA - (void)depend:(NSObject<InterfaceH> *)classB { if ([classB respondsToSelector:@selector(method1)]) { [classB method1]; } if ([classB respondsToSelector:@selector(method2)]) { [classB method2]; } if ([classB respondsToSelector:@selector(method5)]) { [classB method5]; } } @end //================== ClassD.h ================== @interface ClassD : NSObject <InterfaceH> @end @implementation ClassD - (void)method1 { //not necessarily } - (void)method2 { //not necessarily } - (void)method3 { NSLog(@"類 D 實現介面 H 的方法3"); } - (void)method4 { NSLog(@"類 D 實現介面 H 的方法4"); } - (void)method5 { NSLog(@"類 D 實現介面 H 的方法5"); } @end //================== ClassC.h ================== @interface ClassC : NSObject - (void)depend:(NSObject<InterfaceH> *)classD; @end @implementation ClassC - (void)depend:(NSObject<InterfaceH> *)classD { if ([classD respondsToSelector:@selector(method3)]) { [classD method3]; } if ([classD respondsToSelector:@selector(method4)]) { [classD method4]; } if ([classD respondsToSelector:@selector(method5)]) { [classD method5]; } } @end
可以看到，如果介面過於臃腫，只要介面中出現的方法，不管對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。由於介面方法的設計造成了冗餘，因此該設計不符合介面隔離原則。
解決方法：將臃腫的介面 H 拆分為獨立的幾個介面，類 A 和類 C 分別與他們需要的介面建立依賴關係，也就是採用介面隔離原則。
//================== InterfaceH.h ================== @protocol InterfaceH <NSObject> - (void)method5; @end @protocol InterfaceH1 <InterfaceH> - (void)method1; - (void)method2; @end @protocol InterfaceH2 <InterfaceH> - (void)method3; - (void)method4; @end //================== ClassB.h ================== @interface ClassB : NSObject <InterfaceH1> @end @implementation ClassB - (void)method1 { NSLog(@"類 B 實現介面 H 的方法1"); } - (void)method2 { NSLog(@"類 B 實現介面 H 的方法2"); } - (void)method5 { NSLog(@"類 B 實現介面 H 的方法5"); } @end //================== ClassA.h ================== @interface ClassA : NSObject - (void)depend:(NSObject<InterfaceH1> *)classB; @end @implementation ClassA - (void)depend:(NSObject<InterfaceH1> *)classB { if ([classB respondsToSelector:@selector(method1)]) { [classB method1]; } if ([classB respondsToSelector:@selector(method2)]) { [classB method2]; } if ([classB respondsToSelector:@selector(method5)]) { [classB method5]; } } @end //================== ClassD.h ================== @interface ClassD : NSObject <InterfaceH2> @end @implementation ClassD - (void)method3 { NSLog(@"類 D 實現介面 H 的方法3"); } - (void)method4 { NSLog(@"類 D 實現介面 H 的方法4"); } - (void)method5 { NSLog(@"類 D 實現介面 H 的方法5"); } @end //================== ClassC.h ================== @interface ClassC : NSObject - (void)depend:(NSObject<InterfaceH2> *)classD; @end @implementation ClassC - (void)depend:(NSObject<InterfaceH2> *)classD { if ([classD respondsToSelector:@selector(method3)]) { [classD method3]; } if ([classD respondsToSelector:@selector(method4)]) { [classD method4]; } if ([classD respondsToSelector:@selector(method5)]) { [classD method5]; } } @end
介面隔離原則的含義是：建立單一介面，不要建立龐大臃腫的介面，儘量細化介面，介面中的方法儘量少。在實際專案開發中，只暴露給呼叫的類需要的方法，不需要的方法則隱藏起來。只有專注地為一個模組提供定製服務，才能建立最小的依賴關係，不要試圖去建立一個很龐大的介面供所有依賴它的類去呼叫。通過分散定義多個介面，可以預防外來變更的擴散，提高系統的靈活性和可維護性。
原則五、迪米特法則（Law of Demeter，簡稱LOD）
定義：一個物件應該對其他物件保持最少的瞭解。
當類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都儘量地的將邏輯封裝在類的內部，對外只暴露必要的介面。
解決方案：儘量降低類與類之間的耦合。
比如，有一個集團公司，下屬單位有分公司和直屬部門，現在要求打印出所有下屬單位的員工 ID ：
Model 類，
//================== EmployeeModel.h ================== @interface EmployeeModel : NSObject /** 總公司員工ID */ @property (nonatomic, copy) NSString *employee_id; @end //================== SubEmployeeModel.h ================== @interface SubEmployeeModel : NSObject /** 分公司員工ID */ @property (nonatomic, copy) NSString *subemployee_id; @end
Company 類，
//================== Company.h ================== @interface Company : NSObject - (NSArray *)getAllEmployee; - (void)printAllEmployeeWithSubCompany:(SubCompany *)subCompany; @end @implementation Company - (NSArray *)getAllEmployee { NSMutableArray<EmployeeModel *> *employeeArray = [NSMutableArray<EmployeeModel *> array]; for (int i = 0; i < 3; i++) { EmployeeModel *employeeModel = [[EmployeeModel alloc] init]; [employeeModel setEmployee_id:[@(i) stringValue]]; [employeeArray addObject:employeeModel]; } return employeeArray.copy; } - (void)printAllEmployeeWithSubCompany:(SubCompany *)subCompany { // 分公司員工 NSArray<SubEmployeeModel *> *subEmployeeArray = subCompany.getAllEmployee; for (SubEmployeeModel *employeeModel in subEmployeeArray) { NSLog(@"分公司員工ID:%@", employeeModel.subemployee_id); } // 總公司員工 NSArray<EmployeeModel *> *employeeArray = self.getAllEmployee; for (EmployeeModel *employeeModel in employeeArray) { NSLog(@"總公司員工ID:%@", employeeModel.employee_id); } } @end //================== SubCompany.h ================== @interface SubCompany : NSObject - (NSArray *)getAllEmployee; @end @implementation SubCompany - (NSArray *)getAllEmployee { NSMutableArray<SubEmployeeModel *> *employeeArray = [NSMutableArray<SubEmployeeModel *> array]; for (int i = 0; i < 3; i++) { SubEmployeeModel *employeeModel = [[SubEmployeeModel alloc] init]; [employeeModel setSubemployee_id:[@(i) stringValue]]; [employeeArray addObject:employeeModel]; } return employeeArray.copy; } @end
從上面可以看出，列印 Company 所有員工的 ID ，需要依賴分公司 SubCompany 。但是在 printAllEmployeeWithSubCompany: 方法裡面必須要初始化分公司員工 SubEmployeeModel 。而 SubEmployeeModel 和 Company 並不是直接聯絡，換句話說，總公司 Company 只需要依賴分公司 SubCompany ，與分公司的員工 SubEmployeeModel 並沒有任何聯絡，這樣設計顯然是增加了不必要的耦合。
按照迪米特法則，類與類之間的應該減少不必要的關聯程度。
//================== Company.h ================== @interface Company : NSObject /** 獲取所有分公司員工 */ - (NSArray *)getAllEmployee; /** 列印公司所有員工 */ - (void)printAllEmployeeWithSubCompany:(SubCompany *)subCompany; @end @implementation Company - (NSArray *)getAllEmployee { NSMutableArray<EmployeeModel *> *employeeArray = [NSMutableArray<EmployeeModel *> array]; for (int i = 0; i < 3; i++) { EmployeeModel *employeeModel = [[EmployeeModel alloc] init]; [employeeModel setEmployee_id:[@(i) stringValue]]; [employeeArray addObject:employeeModel]; } return employeeArray.copy; } - (void)printAllEmployeeWithSubCompany:(SubCompany *)subCompany { // 分公司員工 [subCompany printAllEmployee]; // 總公司員工 NSArray<EmployeeModel *> *employeeArray = self.getAllEmployee; for (EmployeeModel *employeeModel in employeeArray) { NSLog(@"總公司員工ID:%@", employeeModel.employee_id); } } @end //================== SubCompany.h ================== @interface SubCompany : NSObject /** 獲取所有分公司員工 */ - (NSArray *)getAllEmployee; /** 列印分公司所有員工 */ - (void)printAllEmployee; @end @implementation SubCompany - (NSArray *)getAllEmployee { NSMutableArray<SubEmployeeModel *> *employeeArray = [NSMutableArray<SubEmployeeModel *> array]; for (int i = 0; i < 3; i++) { SubEmployeeModel *employeeModel = [[SubEmployeeModel alloc] init]; [employeeModel setSubemployee_id:[@(i) stringValue]]; [employeeArray addObject:employeeModel]; } return employeeArray.copy; } - (void)printAllEmployee { // 分公司員工 NSArray<SubEmployeeModel *> *subEmployeeArray = self.getAllEmployee; for (SubEmployeeModel *employeeModel in subEmployeeArray) { NSLog(@"分公司員工ID:%@", employeeModel.subemployee_id); } } @end
修改後，為分公司增加了列印所有公鑰 ID 的方法，總公司直接調分公司的列印方法，從而避免了與分公司的員工發生耦合。
耦合的方式很多，依賴、關聯、組合、聚合等。
迪米特法則的初衷是降低類之間的耦合，由於每個類都減少了不必要的依賴，因此的確可以降低耦合關係。但是過分的使用迪米特原則，會產生大量傳遞類，導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。
原則六、開閉原則（Open Close Principle，簡稱OCP）
定義：一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。
核心思想： 儘量通過擴充套件應用程式中的類、模組和函式來解決不同的需求場景，而不是通過直接修改已有的類、模組和函式。
用抽象構建框架，用實現擴充套件細節，對擴充套件開放的關鍵是抽象，而物件的多型則保證了這種擴充套件的開放性。開放原則首先意味著我們可以自由地增加功能，而不會影響原有功能。這就要求我們能夠通過繼承完成功能的擴充套件。其次，開放原則還意味著實現是可替換的。只有利用抽象，才可以為定義提供不同的實現，然後根據不同的需求例項化不同的實現子類。
開放封閉原則的優點：
- 程式碼可讀性高，可維護性強。
- 幫助縮小邏輯粒度，以提高可複用性。
- 可以使維護人員只擴充套件一個類，而非修改一個類，從而提高可維護性。
- 在設計之初考慮所有可能變化的因素，留下介面，從而符合面向物件開發的要求。
比如，書店售書的經典例子：
//================== IBookProtocol.h ================== @protocol IBookProtocol <NSObject> /** 獲取書籍名稱 */ - (NSString *)bookName; /** 獲取書籍售價 */ - (CGFloat)bookPrice; /** 獲取書籍作者 */ - (NSString *)bookAuthor; @end //================== NovelBook.h ================== @interface NovelBook : NSObject <IBookProtocol> - (instancetype)initWithBookName:(NSString *)name price:(CGFloat)price author:(NSString *)author; @end //================== BookStore.h ================== @interface BookStore : NSObject - (NSArray<IBookProtocol> *)bookArray; @end //================== main 函式 ================== // 模擬書店賣書 BookStore *bookStore = [BookStore new]; for (NovelBook *novelBook in bookStore.bookArray) { NSLog(@"書籍名稱：%@ 書籍作者：%@ 書籍價格：%2f", [novelBook bookName], [novelBook bookAuthor], [novelBook bookPrice]); }
執行結果如下，
2018-11-12 15:11:32.642070+0800 DesignPatterns[1863:5763476] 書籍名稱：天龍八部 書籍作者：金庸 書籍價格：50.000000 2018-11-12 15:11:32.642495+0800 DesignPatterns[1863:5763476] 書籍名稱：巴黎聖母院 書籍作者：雨果 書籍價格：70.000000 2018-11-12 15:11:32.642530+0800 DesignPatterns[1863:5763476] 書籍名稱：悲慘世界 書籍作者：雨果 書籍價格：80.000000 2018-11-12 15:11:32.642558+0800 DesignPatterns[1863:5763476] 書籍名稱：金瓶梅 書籍作者：蘭陵王 書籍價格：40.000000
將來某一天需求變更為專案投產，書店盈利，書店決定， 40 元以上打 8 折， 40 元以下打 9 折。
在實際的專案開發中，如果不懂得開閉原則的話，很容易犯下面的錯誤：
- 在
IBookProtocol上新增加一個方法bookOffPrice()方法，專門進行打折，所有實現類實現這個方法，但是如果其他不想打折的書籍也會因為實現了書籍的介面必須打折。 - 修改
NovelBook實現類中的bookPrice()方中實現打折處理，由於該方法已經實現了打折處理價格，因此採購書籍人員看到的也是打折後的價格的情況。
很顯然按照上面兩種方案的話，隨著需求的增加，需要反覆修改之前建立的類，給新增的類造成了不必要的冗餘，業務邏輯的處理和需求不相符合等情況。
//================== OffNovelBook.h ================== @interface OffNovelBook : NovelBook @end @implementation OffNovelBook - (instancetype)initWithBookName:(NSString *)name price:(CGFloat)price author:(NSString *)author { return [super initWithBookName:name price:price author:author]; } - (CGFloat)bookPrice { CGFloat originalPrice = [super bookPrice]; CGFloat offPrice= 0; if (originalPrice > 40) { offPrice = originalPrice * 0.8; } else { offPrice = originalPrice * 0.9; } return offPrice; } @end //================== BookStore.h ================== @interface BookStore : NSObject - (NSArray<IBookProtocol> *)bookArray; - (NSArray<IBookProtocol> *)offBookArray; @end @implementation BookStore - (NSArray<IBookProtocol> *)bookArray { NSMutableArray<IBookProtocol> *tempArray = [NSMutableArray<IBookProtocol> array]; NovelBook *book1 = [[NovelBook alloc] initWithBookName:@"天龍八部" price:30 author:@"金庸"]; [tempArray addObject:book1]; NovelBook *book2 = [[NovelBook alloc] initWithBookName:@"巴黎聖母院" price:70 author:@"雨果"]; [tempArray addObject:book2]; NovelBook *book3 = [[NovelBook alloc] initWithBookName:@"悲慘世界" price:80 author:@"雨果"]; [tempArray addObject:book3]; NovelBook *book4 = [[NovelBook alloc] initWithBookName:@"金瓶梅" price:40 author:@"蘭陵王"]; [tempArray addObject:book4]; return tempArray; } - (NSArray<IBookProtocol> *)offBookArray { NSMutableArray<IBookProtocol> *tempArray = [NSMutableArray<IBookProtocol> array]; OffNovelBook *book1 = [[OffNovelBook alloc] initWithBookName:@"天龍八部" price:30 author:@"金庸"]; [tempArray addObject:book1]; OffNovelBook *book2 = [[OffNovelBook alloc] initWithBookName:@"巴黎聖母院" price:70 author:@"雨果"]; [tempArray addObject:book2]; OffNovelBook *book3 = [[OffNovelBook alloc] initWithBookName:@"悲慘世界" price:80 author:@"雨果"]; [tempArray addObject:book3]; OffNovelBook *book4 = [[OffNovelBook alloc] initWithBookName:@"金瓶梅" price:40 author:@"蘭陵王"]; [tempArray addObject:book4]; return tempArray; } @end //================== main 函式 ================== BookStore *bookStore = [BookStore new]; NSLog(@"------------書店賣出去的原價書籍記錄如下：------------"); for (NovelBook *novelBook in bookStore.bookArray) { NSLog(@"書籍名稱：%@ 書籍作者：%@ 書籍價格：%2f", [novelBook bookName], [novelBook bookAuthor], [novelBook bookPrice]); } NSLog(@"------------書店賣出去的打折書籍記錄如下：------------"); for (OffNovelBook *novelBook in bookStore.offBookArray) { NSLog(@"書籍名稱：%@ 書籍作者：%@ 書籍價格：%2f", [novelBook bookName], [novelBook bookAuthor], [novelBook bookPrice]); }
執行結果如下，
2018-11-12 15:52:01.639550+0800 DesignPatterns[2962:6151804] ------------書店賣出去的原價書籍記錄如下：------------ 2018-11-12 15:52:01.639895+0800 DesignPatterns[2962:6151804] 書籍名稱：天龍八部 書籍作者：金庸 書籍價格：30.000000 2018-11-12 15:52:01.639927+0800 DesignPatterns[2962:6151804] 書籍名稱：巴黎聖母院 書籍作者：雨果 書籍價格：70.000000 2018-11-12 15:52:01.639951+0800 DesignPatterns[2962:6151804] 書籍名稱：悲慘世界 書籍作者：雨果 書籍價格：80.000000 2018-11-12 15:52:01.639971+0800 DesignPatterns[2962:6151804] 書籍名稱：金瓶梅 書籍作者：蘭陵王 書籍價格：40.000000 2018-11-12 15:52:01.639988+0800 DesignPatterns[2962:6151804] ------------書店賣出去的打折書籍記錄如下：------------ 2018-11-12 15:52:01.640029+0800 DesignPatterns[2962:6151804] 書籍名稱：天龍八部 書籍作者：金庸 書籍價格：27.000000 2018-11-12 15:52:01.640145+0800 DesignPatterns[2962:6151804] 書籍名稱：巴黎聖母院 書籍作者：雨果 書籍價格：56.000000 2018-11-12 15:52:01.640194+0800 DesignPatterns[2962:6151804] 書籍名稱：悲慘世界 書籍作者：雨果 書籍價格：64.000000 2018-11-12 15:52:01.640217+0800 DesignPatterns[2962:6151804] 書籍名稱：金瓶梅 書籍作者：蘭陵王 書籍價格：36.000000
在實際的專案開發中，
-
對抽象定義的修改，要保證定義的介面或者
Protocol的穩定，尤其要保證被其他物件呼叫的介面的穩定；否則，就會導致修改蔓延，牽一髮而動全身。 -
對具體實現的修改，因為具體實現的修改，可能會給呼叫者帶來意想不到的結果。如果確實需要修改具體的實現，就需要做好達到測試覆蓋率要求的單元測試。