1、第2章面向對象設計原則劉劉 偉偉weiliu_本章教學內容w 面向對象設計原則概述w 單一職責原則w 開閉原則w 里氏代換原則w 依賴倒轉原則w 接口隔離原則w 合成復用原則w 迪米特法則面向對象設計原則概述w 軟件的可維護性和可復用性 知名軟件大師知名軟件大師Robert C.Martin認為一個可維護性認為一個可維護性(Maintainability) 較低的軟件設計，通常由于如下較低的軟件設計，通常由于如下4個原因造成：個原因造成： 過于僵硬(Rigidity) 過于脆弱(Fragility) 復用率低(Immobility) 黏度過高(Viscosity) Robert C.Marti

2、n面向對象設計原則概述w 軟件的可維護性和可復用性軟件工程和建模大師軟件工程和建模大師Peter Coad認為，一個好的系統認為，一個好的系統設計應該具備如下三個性質：設計應該具備如下三個性質： 可擴展性(Extensibility) 靈活性(Flexibility) 可插入性(Pluggability) Peter Coad面向對象設計原則概述w 軟件的可維護性和可復用性 軟件的復用軟件的復用(Reuse)或重用或重用擁有眾多優點，如可以提高軟件擁有眾多優點，如可以提高軟件的開發效率，提高軟件質量，節約開發成本，的開發效率，提高軟件質量，節約開發成本，恰當的復用還恰當的復用還可以改善系統的可

3、維護性可以改善系統的可維護性。 面向對象設計復用的目標在于面向對象設計復用的目標在于實現支持可維護性的復用。實現支持可維護性的復用。 在面向對象的設計里面，在面向對象的設計里面，可維護性復用都是以面向對象設計可維護性復用都是以面向對象設計原則為基礎的原則為基礎的，這些設計原則首先都是復用的原則，遵循這，這些設計原則首先都是復用的原則，遵循這些設計原則可以有效地提高系統的復用性，同時提高系統的些設計原則可以有效地提高系統的復用性，同時提高系統的可維護性。可維護性。 面向對象設計原則概述w 軟件的可維護性和可復用性面向對象設計原則和設計模式也是對系統進行合理重構面向對象設計原則和設計模式也是對系統

4、進行合理重構的指南針，的指南針，重構重構(Refactoring)是是在不改變軟件現有功在不改變軟件現有功能的基礎上，通過調整程序代碼改善軟件的質量、性能，能的基礎上，通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性性和維護性。 Martin Fowler面向對象設計原則概述w 面向對象設計原則簡介 常用的面向對象設計原則包括常用的面向對象設計原則包括7個，這些原則并不是孤立存在的，它們相個，這些原則并不是孤立存在的，它們相互依賴，相互補充?；ヒ蕾?，相互補充。設計原則名稱設計原則名稱設計原則簡介設計

5、原則簡介重要性重要性單一職責原則(Single Responsibility Principle, SRP)類的職責要單一，不能將太多的職責放在一個類中開閉原則(Open-Closed Principle, OCP)軟件實體對擴展是開放的，但對修改是關閉的，即在不修改一個軟件實體的基礎上去擴展其功能里氏代換原則(Liskov Substitution Principle, LSP)在軟件系統中，一個可以接受基類對象的地方必然可以接受一個子類對象依賴倒轉原則(Dependency Inversion Principle, DIP)要針對抽象層編程，而不要針對具體類編程接口隔離原則(Interfa

6、ce Segregation Principle, ISP)使用多個專門的接口來取代一個統一的接口 合成復用原則(Composite Reuse Principle, CRP)在系統中應該盡量多使用組合和聚合關聯關系，盡量少使用甚至不使用繼承關系迪米特法則(Law of Demeter, LoD)一個軟件實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用，而是通過引入一個第三者發生間接交互單一職責原則 w 單一職責原則定義 單一職責原則單一職責原則(Single Responsibility Principle, SRP)定義如下：定義如下：

7、 一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中。 其英文定義為：其英文定義為： Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. 另一種定義方式如下：另一種定義方式如下： 就一個類而言，應該僅有一個引起它變化的原因。 其英文定義為：其英文定義為： There should never be more than one reason for a class to change.單一職責原則

8、w 單一職責原則分析 一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。作。 類的職責主要包括兩個方面：類的職責主要包括兩個方面：數據職責和行為職責數據職責和行為職責，數據職責通過數據職責通過其屬性來體現其屬性來體現，而，而行為職責通過其方法來體現行為職責通過其方法來體現。 單一職責原則是實現單一

9、職責原則是實現高內聚、低耦合高內聚、低耦合的指導方針，在很多代碼重構的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。設計人員具有較強的分析設計能力和相關重構經驗。單一職責原則 w 單一職責原則實例 實例說明實例說明 某基于Java的C/S系統的“登錄功能”通過如下登錄類(Login)實現： 現使用單一職責原則對其進行重構。單一職責原則 w 單

10、一職責原則實例 實例解析實例解析 開閉原則w 開閉原則定義 開閉原則開閉原則(Open-Closed Principle, OCP)定義如下：定義如下： 一個軟件實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展，即實現在不修改源代碼的情況下改變這個模塊的行為。其英文定義為：其英文定義為： Software entities should be open for extension, but closed for modification.開閉原則w 開閉原則分析 開閉原則由開閉原則由Bertrand Meyer于于1988年提出，它是面向

11、年提出，它是面向對象設計中最重要的原則之一。對象設計中最重要的原則之一。在開閉原則的定義中，在開閉原則的定義中，軟件實體可以指一個軟件模塊、軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類一個由多個類組成的局部結構或一個獨立的類。開閉原則w 開閉原則分析 抽象化抽象化是開閉原則的關鍵。是開閉原則的關鍵。 開閉原則還可以通過一個更加具體的開閉原則還可以通過一個更加具體的“對可變性封對可變性封裝原則裝原則”來描述，對可變性封裝原則來描述，對可變性封裝原則(Principle of Encapsulation of Variation, EVP)要求找到系統要求找到系統的可變因素

12、并將其封裝起來。的可變因素并將其封裝起來。 開閉原則w 開閉原則實例 實例說明實例說明 某圖形界面系統提供了各種不同形狀的按鈕，客戶端代碼可針對這些按鈕進行編程，用戶可能會改變需求要求使用不同的按鈕，原始設計方案如圖所示： 現對該系統進行重構，使之滿足開閉原則的要求。LoginForm- button : CircleButton+ display () : voidCircleButton+ view () : voidLoginForm- button : RectangleButton+ display () : voidRectangleButton+ view () : void開閉

13、原則w 開閉原則實例 實例解析實例解析 里氏代換原則 w 里氏代換原則定義 里氏代換原則里氏代換原則(Liskov Substitution Principle, LSP)有兩種定義方式，有兩種定義方式，第一種定義方式相對嚴格，其定義如下：第一種定義方式相對嚴格，其定義如下： 如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換o2時，程序P的行為沒有變化，那么類型S是類型T的子類型。 其英文定義為：其英文定義為： If for each object o1 of type S there is an object o2 of type T s

14、uch that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. 第二種更容易理解的定義方式如下：第二種更容易理解的定義方式如下： 所有引用基類（父類）的地方必須能透明地使用其子類的對象。 其英文定義為：其英文定義為： Functions that use pointers or references to base classes must be able to use objects

15、 of derived classes without knowing it.里氏代換原則 w 里氏代換原則分析 里氏代換原則由里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授省理工學院教授Barbara Liskov和卡內基和卡內基.梅隆大學梅隆大學Jeannette Wing教教授于授于1994年提出。其原文如下：年提出。其原文如下：Let q(x) be a property provable about objects x of type T. Then q(y) should be true for obje

16、cts y of type S where S is a subtype of T. 芭芭拉芭芭拉利斯科夫（利斯科夫（Barbara Liskov），美國計算機科學家，2008年圖靈獎得主，2004年約翰.馮諾依曼獎得主，美國工程院院士，美國藝術與科學院院士，美國計算機協會會士?，F任麻省理工學院電子電氣與計算機科學系教授。她是美國第一個計算機科學女博士。周以真（周以真（Jeannette M. Wing），美國計算機科學家，卡內基.梅隆大學教授，美國國家自然基金會計算與信息科學工程部助理部長，ACM和IEEE會士。里氏代換原則 w 里氏代換原則分析里氏代換原則可以通俗表述為：在里氏代換原則可以

17、通俗表述為：在軟件中如果能夠使用軟件中如果能夠使用基類對象，那么一定能夠使用其子類對象基類對象，那么一定能夠使用其子類對象。把基類都替。把基類都替換成它的子類，程序將不會產生任何錯誤和異常，反過換成它的子類，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類的話，來則不成立，如果一個軟件實體使用的是一個子類的話，那么它不一定能夠使用基類。那么它不一定能夠使用基類。里氏代換原則是實現開閉原則的重要方式之一，由于使里氏代換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此用基類對象的地方都可以使用子類對象，因此在程序中在程序中盡量使用基類類

18、型來對對象進行定義，而在運行時再確盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象定其子類類型，用子類對象來替換父類對象。里氏代換原則 w 里氏代換原則分析喜歡動物喜歡貓 因為貓是動物 里氏代換原則 w 里氏代換原則實例實例說明實例說明 某系統需要實現對重要數據（如用戶密碼）的加密處理，在數據操作類(DataOperator)中需要調用加密類中定義的加密算法，系統提供了兩個不同的加密類，CipherA和CipherB，它們實現不同的加密方法，在DataOperator中可以選擇其中的一個實現加密操作。如圖所示：里氏代換原則 w 里氏代換原則實例實例說明實例

19、說明 如果需要更換一個加密算法類或者增加并使用一個新的加密算法類，如將CipherA改為CipherB，則需要修改客戶類Client和數據操作類DataOperator的源代碼，違背了開閉原則。 現使用里氏代換原則對其進行重構，使得系統可以靈活擴展，符合開閉原則。里氏代換原則 w 里氏代換原則實例實例解析實例解析 依賴倒轉原則 w 依賴倒轉原則定義 依賴倒轉原則依賴倒轉原則(Dependence Inversion Principle, DIP)的定義的定義如下：如下： 高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節，細節應該依賴于抽象。 其英文定義為：其英文定義為： H

20、igh level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions. 另一種表述為：另一種表述為： 要針對接口編程，不要針對實現編程。 其英文定義為：其英文定義為： Program to an interface, not an implementation.依賴倒轉原則 w 依賴倒轉原則分析 依賴倒

21、轉原則是依賴倒轉原則是Robert C. Martin在在1996年為年為C+ Reporter所寫的專欄所寫的專欄Engineering Notebook的第三篇，后來加入到他在的第三篇，后來加入到他在2002年出版的經典著作年出版的經典著作Agile Software Development, Principles, Patterns, and Practices中。中。依賴倒轉原則 w 依賴倒轉原則分析簡單來說，依賴倒轉原則就是指：簡單來說，依賴倒轉原則就是指：代碼要依賴于抽象的代碼要依賴于抽象的類，而不要依賴于具體的類類，而不要依賴于具體的類；要針對接口或抽象類編程，要針對接口或抽象類

22、編程，而不是針對具體類編程而不是針對具體類編程。實現開閉原則的關鍵是抽象化，并且從抽象化導出具體實現開閉原則的關鍵是抽象化，并且從抽象化導出具體化實現，如果說化實現，如果說開閉原則是面向對象設計的目標的話開閉原則是面向對象設計的目標的話，那么那么依賴倒轉原則就是面向對象設計的主要手段依賴倒轉原則就是面向對象設計的主要手段。 依賴倒轉原則 w 依賴倒轉原則分析依賴倒轉原則的常用實現方式之依賴倒轉原則的常用實現方式之一是一是在代碼中使用抽象類，而將在代碼中使用抽象類，而將具體類放在配置文件中具體類放在配置文件中。 “將抽象放進代碼，將細節放進元數據” Put Abstractions in Cod

23、e, Details in Metadata（程序員修煉之道：從小工到專家(The Pragmatic programmer: from journeyman to master) ）依賴倒轉原則 w 依賴倒轉原則分析類之間的耦合類之間的耦合 零耦合關系 具體耦合關系 抽象耦合關系 依賴倒轉原則要求客戶端依賴于抽象耦合，依賴倒轉原則要求客戶端依賴于抽象耦合，以抽象方以抽象方式耦合是依賴倒轉原則的關鍵式耦合是依賴倒轉原則的關鍵。依賴倒轉原則 w 依賴倒轉原則分析依賴注入依賴注入 依賴倒轉原則 w 依賴倒轉原則分析依賴注入依賴注入 構造注入(Constructor Injection)：通過構造函

24、數注入實例變量。 設值注入(Setter Injection)：通過Setter方法注入實例變量。 接口注入(Interface Injection)：通過接口方法注入實例變量。 依賴倒轉原則w 依賴倒轉原則實例實例說明實例說明 某系統提供一個數據轉換模塊，可以將來自不同數據源的數據轉換成多種格式，如可以轉換來自數據庫的數據(DatabaseSource)、也可以轉換來自文本文件的數據(TextSource)，轉換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。依賴倒轉原則w 依賴倒轉原則實例實例說明實例說明 由于需求的變化，該系

25、統可能需要增加新的數據源或者新的文件格式，每增加一個新的類型的數據源或者新的類型的文件格式，客戶類MainClass都需要修改源代碼，以便使用新的類，但違背了開閉原則?，F使用依賴倒轉原則對其進行重構。 依賴倒轉原則w 依賴倒轉原則實例實例解析實例解析 接口隔離原則w 接口隔離原則定義 接口隔離原則接口隔離原則(Interface Segregation Principle, ISP)的定義如下：的定義如下： 客戶端不應該依賴那些它不需要的接口。 其英文定義為：其英文定義為： Clients should not be forced to depend upon interfaces that

26、they do not use. 注意，在該定義中的接口指的是所定義的方法。注意，在該定義中的接口指的是所定義的方法。 另一種定義方法如下：另一種定義方法如下： 一旦一個接口太大，則需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。 其英文定義為：其英文定義為： Once an interface has gotten too fat it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know ab

27、out the methods that pertain to them. 接口隔離原則w 接口隔離原則分析 接口隔離原則是指使接口隔離原則是指使用多個專門的接口，而不使用單用多個專門的接口，而不使用單一的總接口一的總接口。每一個接口應該承擔一種相對獨立的角。每一個接口應該承擔一種相對獨立的角色，不多不少，不干不該干的事，該干的事都要干。色，不多不少，不干不該干的事，該干的事都要干。 (1) 一個接口就只代表一個角色，每個角色都有它特定的一個接口，此時這個原則可以叫做“角色隔離原則”。 (2) 接口僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的

28、單獨的接口，而不要提供大的總接口。 接口隔離原則w 接口隔離原則分析 使用接口隔離原則拆分接口時，首先必須滿足使用接口隔離原則拆分接口時，首先必須滿足單一職單一職責原則責原則，將一組相關的操作定義在一個接口中，且在，將一組相關的操作定義在一個接口中，且在滿足高內聚的前提下，接口中的方法越少越好。滿足高內聚的前提下，接口中的方法越少越好?？梢栽谶M行系統設計時采用可以在進行系統設計時采用定制服務定制服務的方式，即的方式，即為不為不同的客戶端提供寬窄不同的接口同的客戶端提供寬窄不同的接口，只提供用戶需要的，只提供用戶需要的行為，而隱藏用戶不需要的行為。行為，而隱藏用戶不需要的行為。接口隔離原則w 接

29、口隔離原則實例 實例說明實例說明 下圖展示了一個擁有多個客戶類的系統，在系統中定義了一個巨大的接口（胖接口）AbstractService來服務所有的客戶類?？梢允褂媒涌诟綦x原則對其進行重構。接口隔離原則w 接口隔離原則實例 實例解析實例解析 ClientAAbstractServiceA+ operatorA ().: voidClientBClientCConcreteService+operatorA ()operatorB ()operatorC (): void: void: voidAbstractServiceB+ operatorB ().: voidAbstractServi

30、ceC+ operatorC ().: void合成復用原則w 合成復用原則定義 合成復用原則合成復用原則(Composite Reuse Principle, CRP)又稱為組合又稱為組合/聚合復用原則聚合復用原則(Composition/ Aggregate Reuse Principle, CARP)，其定義如下：，其定義如下： 盡量使用對象組合，而不是繼承來達到復用的目的。 其英文定義為：其英文定義為： Favor composition of objects over inheritance as a reuse mechanism.合成復用原則w 合成復用原則分析 合成復用原則就是

31、指在一個新的對象里通過合成復用原則就是指在一個新的對象里通過關聯關系關聯關系（包括組合關系和聚合關系）（包括組合關系和聚合關系）來使用一些已有的對象，來使用一些已有的對象，使之成為新對象的一部分；新對象使之成為新對象的一部分；新對象通過委派調用已有通過委派調用已有對象的方法達到復用其已有功能的目的對象的方法達到復用其已有功能的目的。簡言之：要。簡言之：要盡量使用組合盡量使用組合/聚合關系，少用繼承聚合關系，少用繼承。合成復用原則w 合成復用原則分析 在面向對象設計中，可以通過兩種基本方法在不同的在面向對象設計中，可以通過兩種基本方法在不同的環境中復用已有的設計和實現，即通過環境中復用已有的設計

32、和實現，即通過組合組合/聚合關系聚合關系或通過或通過繼承繼承。 繼承復用：實現簡單，易于擴展。破壞系統的封裝性；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；只能在有限的環境中使用。（“白箱”復用 ） 組合/聚合復用：耦合度相對較低，選擇性地調用成員對象的操作；可以在運行時動態進行。（“黑箱”復用 ）合成復用原則w 合成復用原則分析 組合組合/聚合可以聚合可以使系統更加靈活使系統更加靈活，類與類之間的，類與類之間的耦合度耦合度降低降低，一個類的變化對其他類造成的影響相對較少，一個類的變化對其他類造成的影響相對較少，因此一般因此一般首選使用組合首選使用組合/聚合來實現復

33、用聚合來實現復用；其次才考慮；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統構建和維護的難度以及系而濫用繼承反而會增加系統構建和維護的難度以及系統的復雜度，因此需要統的復雜度，因此需要慎重使用繼承復用慎重使用繼承復用。合成復用原則w 合成復用原則實例 實例說明實例說明 某教學管理系統部分數據庫訪問類設計如圖所示：合成復用原則w 合成復用原則實例 實例說明實例說明 如果需要更換數據庫連接方式，如原來采用JDBC連接數據庫，現在

34、采用數據庫連接池連接，則需要修改DBUtil類源代碼。如果StudentDAO采用JDBC連接，但是TeacherDAO采用連接池連接，則需要增加一個新的DBUtil類，并修改StudentDAO或TeacherDAO的源代碼，使之繼承新的數據庫連接類，這將違背開閉原則，系統擴展性較差。 現使用合成復用原則對其進行重構。合成復用原則w 合成復用原則實例 實例解析實例解析 DBUtil+ getConnection ().: ConnectionStudentDAO- dBOperator : DBUtil+setDBOperator (DBUtil dBOperator)findStudent

35、ById (String id)findAllStudents ()save (StudentDTO student).: void: StudentDTO: List: intTeacherDAO- dBOperator : DBUtil+setDBOperator (DBUtil dBOperator)findTeacherById (String id)findAllTeachers ()save (TeacherDTO teacher).: void: TeacherDTO: List: intNewDBUtil+ getConnection ().: Connection迪米特法則

36、w 迪米特法則定義 迪米特法則迪米特法則(Law of Demeter, LoD)又稱為最少知識原則又稱為最少知識原則(Least Knowledge Principle, LKP)，它有多種定義方法，其中幾種典，它有多種定義方法，其中幾種典型定義如下：型定義如下： (1) 不要和“陌生人”說話。英文定義為：Dont talk to strangers. (2) 只與你的直接朋友通信。英文定義為：Talk only to your immediate friends. (3) 每一個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位。英文定義為：Each unit

37、should have only limited knowledge about other units: only units closely related to the current unit.迪米特法則 w 迪米特法則分析迪米特法則來自于迪米特法則來自于1987年秋美國東北大學年秋美國東北大學(Northeastern University)一個一個名為名為“Demeter”的的研究項目研究項目。簡單地說，迪米特法則就是指簡單地說，迪米特法則就是指一個軟件實體應當盡可一個軟件實體應當盡可能少的與其他實體發生相互作用能少的與其他實體發生相互作用。這樣，當一個模塊。這樣，當一個模塊修改時

38、，就會盡量少的影響其他的模塊，擴展會相對修改時，就會盡量少的影響其他的模塊，擴展會相對容易，這是對軟件實體之間通信的限制，它要求限制容易，這是對軟件實體之間通信的限制，它要求限制軟件實體之間通信的寬度和深度。軟件實體之間通信的寬度和深度。迪米特法則 w 迪米特法則分析 在迪米特法則中，對于一個對象，其朋友包括以下幾類：在迪米特法則中，對于一個對象，其朋友包括以下幾類： (1) 當前對象本身(this)； (2) 以參數形式傳入到當前對象方法中的對象； (3) 當前對象的成員對象； (4) 如果當前對象的成員對象是一個集合，那么集合中的元素也都是朋友； (5) 當前對象所創建的對象。 任何一個對

39、象，如果滿足上面的條件之一，就是當前對象的任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋朋友友”，否則就是，否則就是“陌生人陌生人”。迪米特法則 w 迪米特法則分析 迪米特法則可分為狹義法則和廣義法則。迪米特法則可分為狹義法則和廣義法則。在狹義的迪米特法則中，在狹義的迪米特法則中，如果兩個類之間不必彼此直接通信如果兩個類之間不必彼此直接通信，那么這兩個類就不應當發生那么這兩個類就不應當發生直接的相互作用直接的相互作用，如果其中的一個類需要調用另一個類的某一個，如果其中的一個類需要調用另一個類的某一個方法的話，可以通過方法的話，可以通過第三者轉發這個調用第三者轉發這個調用。 迪米特法則 w 迪米特法則分析 狹義的迪米特法則：可以狹義的迪米特法則：可以降低類之間的耦合降低類之間的耦合，但是會在系統中增加大量，但是會在系統中增加大量的小方法并散落在系統的各