外觀模式 (Facade Pattern)

定義：

外觀模式（Facade Pattern）是一種結構型設計模式，它通過提供一個統一的高層接口來簡化復雜子系統或庫的訪問。這種模式的關鍵在于，它創建了一個外觀類，這個類封裝了對子系統的一系列復雜交互，使得子系統更易于使用和理解。

外觀模式的主要特點和目的包括：

簡化復雜系統的接口：外觀模式為復雜的內部子系統提供了一個簡單的外部接口。這樣，客戶端在使用這些子系統時只需要與外觀類交互，而不需要了解或直接訪問系統的復雜內部工作。
降低子系統與客戶端之間的耦合度：客戶端通過外觀類與子系統交互，減少了與子系統內部多個模塊的直接依賴。這樣做有助于減少客戶端和子系統之間的耦合，使得系統更易于維護和擴展。
提高使用便利性：外觀模式通過為復雜子系統提供一個簡單明了的接口，使得客戶端在使用這些系統時更加方便。

解決的問題：

復雜子系統的簡化接口：當一個系統變得非常復雜或難以理解時，外觀模式提供了一個簡單的接口，通過這個接口客戶端可以更容易地訪問和使用這個系統。
客戶端與子系統的解耦：在沒有外觀模式的情況下，客戶端可能需要與多個子系統的多個組件直接交互，這會使客戶端與子系統之間的耦合變得復雜。外觀模式允許客戶端通過一個單一的接口與子系統交互，從而降低耦合度。
易于使用和維護：外觀模式使子系統的使用變得更加簡單直接，這不僅使得客戶端代碼變得更簡潔，也使得維護更加容易，因為大部分依賴都集中在外觀接口上。
隱藏系統的復雜性：外觀模式隱藏了其后的復雜子系統，這樣客戶端就不需要了解這些復雜性。這對于降低整體的復雜性、提高系統的可讀性和可維護性非常有幫助。
隔離變化：如果子系統經常更改，那么可以通過修改外觀類來應對這些變化，從而避免直接影響到使用這些子系統的客戶端。

總的來說，外觀模式提供了一種方式來減少系統的復雜性，并為復雜子系統提供了一個簡潔明了的界面，使子系統更易于使用和維護。

使用場景：

簡化復雜系統的訪問：
- 當系統變得非常復雜或難以理解時，使用外觀模式提供一個簡化的接口，使系統更易于使用和理解。
解耦系統和客戶端代碼：
- 如果你想要降低系統中不同層次或不同子系統之間的依賴關系，可以使用外觀模式作為它們之間的中介。
分層架構：
- 在多層架構的程序中，可以使用外觀作為每一層的入口點，這樣層與層之間的交互只通過這些外觀進行，從而簡化依賴關系。
為復雜子系統提供統一接口：
- 當需要為復雜的子系統提供一個清晰簡單的接口時，外觀模式允許用戶通過一個統一的界面與子系統交互。
封裝遺留代碼或庫：
- 對于舊系統或第三方庫進行封裝，以提供更清晰、更簡單的接口，使得老系統或庫更易于被應用程序使用。
減少編譯依賴：
- 外觀模式可以將一個復雜子系統的依賴集中到一個單一的外觀中，這樣當子系統變化時，只影響到外觀類，而不是所有依賴于子系統的代碼。
隔離代碼：
- 當存在多個可能變化的依賴時，外觀模式可以將這些依賴從客戶端代碼隔離出去，提高子系統的獨立性和可移植性。

外觀模式是一種簡單卻功能強大的模式，特別適合用于簡化復雜系統，減少系統間的耦合，并提高代碼的可維護性和可擴展性。

示例代碼 1 - 簡單外觀模式：

// 子系統類
class SubSystemOne {void methodOne() {System.out.println("SubSystemOne Method");}
}class SubSystemTwo {void methodTwo() {System.out.println("SubSystemTwo Method");}
}class SubSystemThree {void methodThree() {System.out.println("SubSystemThree Method");}
}// 外觀類
class Facade {private SubSystemOne one;private SubSystemTwo two;private SubSystemThree three;public Facade() {one = new SubSystemOne();two = new SubSystemTwo();three = new SubSystemThree();}void methodA() {one.methodOne();two.methodTwo();}void methodB() {two.methodTwo();three.methodThree();}
}

示例代碼 2 - 使用外觀模式簡化接口：

// 復雜系統的各個組件
class CPU {void start() {System.out.println("CPU is starting.");}
}class Memory {void load() {System.out.println("Memory is loading.");}
}class HardDrive {void read() {System.out.println("Reading from hard drive.");}
}// 外觀類
class ComputerFacade {private CPU cpu;private Memory memory;private HardDrive hardDrive;public ComputerFacade() {this.cpu = new CPU();this.memory = new Memory();this.hardDrive = new HardDrive();}public void startComputer() {cpu.start();memory.load();hardDrive.read();System.out.println("Computer started successfully.");}
}

主要符合的設計原則：

單一職責原則（Single Responsibility Principle）:
- 外觀模式提供了一個統一的接口來訪問子系統，這個接口的職責單一：封裝子系統的復雜性并提供簡單的接口。這樣，子系統本身和外觀之間的關注點是分開的。
開閉原則（Open-Closed Principle）:
- 外觀模式使得客戶端代碼可以在不修改子系統的代碼的情況下使用子系統。子系統可以獨立于客戶端和外觀類變化和發展，只要外觀的接口保持不變，客戶端代碼不需要做出任何改變。
最少知識原則（Principle of Least Knowledge）/迪米特法則（Law of Demeter）:
- 外觀模式鼓勵減少系統間的直接交互，客戶端只需要知道外觀接口，不需要了解子系統的內部實現細節，從而減少了系統間的依賴和耦合。

通過使用外觀模式，可以將復雜的系統背后的復雜性隱藏起來，提供簡單的接口，使得客戶端代碼更加清晰、易于理解和維護。同時，這種模式幫助維護系統各部分之間的獨立性和可擴展性。

在JDK中的應用：

java.lang.Class:
- java.lang.Class 類提供了對 Java 反射功能的高級封裝。它隱藏了 Java 反射 API 的復雜性，允許用戶以更簡單的方式處理反射操作，例如獲取類的方法、構造函數、成員變量等。
Java數據庫連接（JDBC）API:
- JDBC API 提供了簡化數據庫操作的接口，封裝了底層的數據庫訪問細節。例如，java.sql.DriverManager 類提供了一個簡化的方法來建立數據庫連接。
java.net.URL 和 java.net.URLConnection:
- 這些類提供了簡化的方法來處理網絡連接和數據傳輸。用戶可以通過 URL 類的簡單接口來訪問和操作網絡資源，而不需要深入了解底層網絡通信的細節。
Java NIO Files API:
- Java NIO中的 java.nio.file.Files 類提供了一系列靜態方法，用于簡化文件操作，如讀取、寫入、復制和移動文件。這些方法封裝了文件操作的復雜性。

雖然在JDK中這些例子并不總是被標記為外觀模式的經典應用，但它們確實遵循了外觀模式的核心理念：提供簡化的接口來隱藏底層的復雜性，使得復雜的操作對用戶來說更加友好和易于使用。

在Spring中的應用：

Spring Web MVC的DispatcherServlet:
- DispatcherServlet作為前端控制器（Front Controller），為Spring Web MVC提供了一個集中的請求處理機制。它封裝了處理HTTP請求的復雜流程，如路由請求、調用控制器、返回響應等，簡化了Web應用的開發。
Spring的JdbcTemplate:
- JdbcTemplate是Spring提供的一個類，用于簡化JDBC操作。它封裝了創建連接、執行SQL語句、處理結果集等JDBC操作的復雜性，提供了一個更簡潔和易用的接口。
Spring Security的配置類:
- Spring Security的配置類，如WebSecurityConfigurerAdapter，提供了一種簡化的方式來配置安全性相關的各種細節，如認證、授權等。它隱藏了安全性配置的復雜性，使開發者能夠輕松地為應用程序添加安全性功能。
Spring Boot的自動配置:
- Spring Boot的自動配置類似于外觀模式的應用，它封裝了Spring應用程序的常見配置，簡化了Spring應用程序的配置過程。開發者只需少量配置或無需任何配置，即可運行起一個Spring應用程序。