8.1 分解就是一切
為了清楚起見，一張來自一篇好文章“面向對象系統的解耦”的圖片說明了將要討論的要點。
您還認為設計應用程序架構很容易嗎？
8.2 接口，實現隱藏
降低系統耦合度的主要原則是OOP的原則和其背後的封裝+抽象+多態的原則。
因此：
- 模塊應該是彼此的“黑盒子”（封裝）。這意味著一個模塊不應該“爬升”到另一個模塊並且不知道它的內部結構。一個子系統中的對像不應該直接訪問另一個子系統中的對象。
- 模塊/子系統應該僅通過接口（即不依賴於實現細節的抽象）相互交互。因此，每個模塊都必須有一個或多個定義良好的接口，用於與其他模塊交互。
“黑盒”（封裝）原則允許我們獨立於其他子系統來考慮每個子系統的結構。該模塊是一個“黑盒子”，可以相對自由地更改。問題只會出現在不同模塊（或模塊和環境）的交界處。
而這個交互必須用最一般（抽象）的形式來描述，也就是用接口的形式。在這種情況下，代碼將與任何符合接口契約的實現一樣工作。正是這種通過稱為多態性的統一接口與不同實現（模塊或對象）一起工作的能力。
這就是為什麼Servlet 是一個接口：Web 容器對 Servlet 一無所知，因為這些是實現 Servlet 接口的一些對象，僅此而已。Servlets 也知道一點容器的結構。Servlet 接口是使 Java Web 應用程序接管世界所需的契約、標準和最小交互。
多態性根本不是方法的覆蓋，正如有時被錯誤地認為的那樣，但首先是具有相同接口或“一個接口，許多實現”的模塊/對象的互換性。實現多態，根本不需要繼承機制。理解這一點很重要，因為通常應盡可能避免繼承。
得益於接口和多態性，正是實現了在不改變已經編寫的內容的情況下修改和擴展代碼的能力（開閉原則）。
只要模塊的交互完全以接口的形式描述並且不依賴於特定的實現，您就有機會絕對“無痛地”為系統用實現相同接口的任何其他模塊替換一個模塊，以及添加一個新的，從而擴展功能。
就像在 LEGO 構造器中一樣 - 接口標準化了交互，並充當了一種連接器，可以連接任何具有合適連接器的模塊。
設計人員的靈活性得到保證，因為我們可以簡單地將一個模塊或部件替換為具有相同連接器（具有相同接口）的另一個模塊或部件，以及添加我們喜歡的任意數量的新部件（同時，現有的零件不會以任何方式改變或改變）。
接口允許您構建更簡單的系統，將每個子系統視為一個整體並忽略其內部結構。它們允許模塊進行交互，同時對彼此的內部結構一無所知，從而充分貫徹了最少知識原則，這是鬆散耦合的基礎。
定義的接口越通用/抽象，它們對交互施加的限制越少，系統就越靈活。從這裡開始，實際上遵循了 SOLID 的另一個原則——接口隔離原則，它反對“厚接口”。
他說，大而笨重的接口應該被分解成更小、更具體的接口，這樣小接口（依賴模塊）的客戶只知道他們需要使用的方法。
該原則表述如下：“客戶不應依賴他們不使用的方法（注意方法）”或“許多專用接口優於一個通用接口”。
事實證明，只有借助於接口，即抽象來描述模塊之間的交互和依賴關係，而無需使用有關其內部結構和結構的知識，才能提供弱連接，實際上實現了封裝。另外，我們有能力通過添加和使用不同的實現來擴展/改變系統的行為，也就是說，由於多態性。是的，我們又來到了OOP——封裝、抽象、多態。
8.3 Facade：模塊接口
這裡有經驗的程序員會問：如果不是在對象層面設計，而是在模塊層面設計，那麼模塊接口的實現是什麼？
答：用設計模式的語言來說，那麼可以有一個專門的對象來負責模塊接口的實現——Facade。如果您在包含 Gateway 後綴（例如，MobileApiGateway）的對像上調用方法，那麼它很可能是一個外觀。
外觀是一個接口對象，它積累了一組用於處理某個子系統的高級操作，隱藏了其內部結構和真正的複雜性。針對子系統實現中的更改提供保護。作為一個單一的入口點——“你踢門面，他知道誰需要踢這個子系統才能得到他需要的東西。”
您剛剛了解了最重要的設計模式之一，它允許您在設計模塊時使用接口的概念，從而將它們解耦——“Facade”。
此外，“Facade”使得以與處理普通對象相同的方式處理模塊成為可能，並在設計模塊時應用類設計中使用的所有有用原則和技術。
注意：雖然大多數程序員在設計類（對象）時都了解接口的重要性，但似乎許多人也發現了在模塊級別使用接口的想法。