一文搞懂設(shè)計(jì)模式—門面模式
軟件開發(fā)過(guò)程中,我們經(jīng)常會(huì)遇到復(fù)雜系統(tǒng),其中包含多個(gè)子系統(tǒng)和接口。在這種情況下,為了簡(jiǎn)化客戶端的調(diào)用過(guò)程,提高代碼的可維護(hù)性和可讀性,我們可以使用門面模式。
門面模式(Facade Pattern)也叫做外觀模式,是一種結(jié)構(gòu)型設(shè)計(jì)模式。它提供一個(gè)統(tǒng)一的接口,封裝了一個(gè)或多個(gè)子系統(tǒng)的復(fù)雜功能,并向客戶端提供一個(gè)簡(jiǎn)單的調(diào)用方式。通過(guò)引入門面,客戶端無(wú)需直接與子系統(tǒng)交互,而只需要通過(guò)門面來(lái)與子系統(tǒng)進(jìn)行通信。
門面模式中包含以下角色:
- 門面(Facade):門面角色是門面模式的核心,它封裝了系統(tǒng)內(nèi)部復(fù)雜子系統(tǒng)的接口,為客戶端提供一個(gè)簡(jiǎn)單的高層接口。門面角色知道哪些子系統(tǒng)負(fù)責(zé)處理請(qǐng)求,并將請(qǐng)求轉(zhuǎn)發(fā)給相應(yīng)的子系統(tǒng)進(jìn)行處理。
- 子系統(tǒng)(Subsystem):子系統(tǒng)角色是實(shí)際執(zhí)行系統(tǒng)功能的組件。每個(gè)子系統(tǒng)都有自己的職責(zé)和行為,通過(guò)門面角色對(duì)外提供服務(wù)。
- 客戶端(Client):客戶端角色通過(guò)調(diào)用門面角色提供的高層接口來(lái)使用系統(tǒng)功能,而無(wú)需直接與子系統(tǒng)交互。
在門面模式中,門面角色充當(dāng)了客戶端和子系統(tǒng)之間的中介者,隱藏了子系統(tǒng)的復(fù)雜性,簡(jiǎn)化了客戶端的調(diào)用過(guò)程??蛻舳酥恍枰c門面角色進(jìn)行交互,而不需要了解和處理子系統(tǒng)的具體細(xì)節(jié)。
注意:門面對(duì)象只是提供一個(gè)訪問(wèn)子系統(tǒng)的一個(gè)路徑而已,它不應(yīng)該也不能參與具體的業(yè)務(wù)邏輯,否則就會(huì)產(chǎn)生一個(gè)倒依賴的問(wèn)題:子系統(tǒng)必須依賴門面才能被訪問(wèn),這是設(shè)計(jì)上一個(gè)嚴(yán)重錯(cuò)誤,不僅違反了單一職責(zé)原則,同時(shí)也破壞了系統(tǒng)的封裝性。
使用場(chǎng)景
門面模式適用于以下情況:
- 當(dāng)一個(gè)系統(tǒng)有很多復(fù)雜的子系統(tǒng)時(shí),可以使用門面模式將其封裝起來(lái),隱藏內(nèi)部復(fù)雜性,簡(jiǎn)化客戶端的調(diào)用。
- 當(dāng)需要將客戶端與復(fù)雜的子系統(tǒng)解耦,降低系統(tǒng)之間的依賴時(shí),可以使用門面模式。
以下是一個(gè)簡(jiǎn)單的示例,展示了門面模式在電子商務(wù)系統(tǒng)中的應(yīng)用。
假設(shè)我們的電子商務(wù)系統(tǒng)包含了訂單管理、庫(kù)存管理和支付管理等子系統(tǒng)。為了簡(jiǎn)化客戶端的調(diào)用過(guò)程,我們可以使用門面模式來(lái)封裝這些子系統(tǒng),并提供一個(gè)統(tǒng)一的接口。
// 訂單管理子系統(tǒng)
class OrderService {
public void createOrder() {
// 創(chuàng)建訂單的具體實(shí)現(xiàn)
}
}
// 庫(kù)存管理子系統(tǒng)
class InventoryService {
public void checkStock() {
// 檢查庫(kù)存的具體實(shí)現(xiàn)
}
}
// 支付管理子系統(tǒng)
class PaymentService {
public void makePayment() {
// 支付的具體實(shí)現(xiàn)
}
}
// 電子商務(wù)門面類
class ECommerceFacade {
private OrderService orderService;
private InventoryService inventoryService;
private PaymentService paymentService;
public ECommerceFacade() {
orderService = new OrderService();
inventoryService = new InventoryService();
paymentService = new PaymentService();
}
// 提供給客戶端的接口
public void placeOrder() {
orderService.createOrder();
inventoryService.checkStock();
paymentService.makePayment();
}
}
在上述示例中,我們創(chuàng)建了一個(gè)電子商務(wù)門面類(ECommerceFacade),它封裝了訂單管理、庫(kù)存管理和支付管理等子系統(tǒng),并提供了一個(gè)簡(jiǎn)單的接口(placeOrder)供客戶端調(diào)用。這樣,客戶端只需要通過(guò)門面類來(lái)完成下單操作,而無(wú)需直接與子系統(tǒng)交互。
門面模式實(shí)現(xiàn)
下面是門面模式的基本結(jié)構(gòu):
// 子系統(tǒng)A
public class SubSystemA {
public void operationA() {
System.out.println("子系統(tǒng)A的操作");
}
}
// 子系統(tǒng)B
public class SubSystemB {
public void operationB() {
System.out.println("子系統(tǒng)B的操作");
}
}
// 子系統(tǒng)C
public class SubSystemC {
public void operationC() {
System.out.println("子系統(tǒng)C的操作");
}
}
// 門面類
public class Facade {
private SubSystemA subSystemA;
private SubSystemB subSystemB;
private SubSystemC subSystemC;
public Facade() {
subSystemA = new SubSystemA();
subSystemB = new SubSystemB();
subSystemC = new SubSystemC();
}
// 提供簡(jiǎn)單的接口給客戶端調(diào)用,隱藏了子系統(tǒng)的復(fù)雜性
public void operation() {
subSystemA.operationA();
subSystemB.operationB();
subSystemC.operationC();
}
}
在上述代碼中,我們有三個(gè)子系統(tǒng)(SubSystemA、SubSystemB、SubSystemC),它們分別實(shí)現(xiàn)了具體的功能。然后,我們創(chuàng)建了一個(gè)門面類(Facade)來(lái)封裝這些子系統(tǒng),并提供了一個(gè)簡(jiǎn)單的接口供客戶端調(diào)用。
優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
- 簡(jiǎn)化客戶端的調(diào)用過(guò)程,隱藏了子系統(tǒng)的復(fù)雜性,提供了一個(gè)統(tǒng)一的接口,客戶端無(wú)需了解子系統(tǒng)的具體實(shí)現(xiàn)。
- 減少系統(tǒng)的相互依賴,解耦了客戶端與子系統(tǒng)之間的依賴關(guān)系。
- 提高了代碼的可維護(hù)性和可讀性。
缺點(diǎn)
- 門面模式可能會(huì)導(dǎo)致門面類變得龐大,承擔(dān)過(guò)多的責(zé)任。
- 如果需要修改子系統(tǒng)的功能,可能需要修改門面類。
門面模式優(yōu)化
在實(shí)際應(yīng)用中,我們可以對(duì)門面模式進(jìn)行一些優(yōu)化和擴(kuò)展。以下是幾個(gè)常見(jiàn)的優(yōu)化實(shí)現(xiàn)方式:
子系統(tǒng)解耦
門面類可以通過(guò)委托來(lái)調(diào)用子系統(tǒng)的功能,而不是直接依賴于具體的子系統(tǒng)。這樣可以使得子系統(tǒng)能夠獨(dú)立演化,不受門面類的影響。
// 門面類
class Facade {
private SubSystemInterface subSystemA;
private SubSystemInterface subSystemB;
public Facade() {
subSystemA = new ConcreteSubSystemA();
subSystemB = new ConcreteSubSystemB();
}
// 提供給客戶端的接口
public void operation() {
subSystemA.operation();
subSystemB.operation();
}
}
// 子系統(tǒng)接口
interface SubSystemInterface {
void operation();
}
// 具體的子系統(tǒng)A
class ConcreteSubSystemA implements SubSystemInterface {
public void operation() {
// 實(shí)現(xiàn)具體的功能
}
}
// 具體的子系統(tǒng)B
class ConcreteSubSystemB implements SubSystemInterface {
public void operation() {
// 實(shí)現(xiàn)具體的功能
}
}
多個(gè)門面類
當(dāng)門面已經(jīng)龐大到不能忍受的程度,承擔(dān)過(guò)多的責(zé)任時(shí),可以考慮使用多個(gè)門面類,每個(gè)門面類負(fù)責(zé)與特定的子系統(tǒng)交互,原則上建議按照功能拆分,比如一個(gè)數(shù)據(jù)庫(kù)操作的門面可以拆分為查詢門面、刪除門面、更新門面等。
// 子系統(tǒng)A的門面類
class SubSystemAFacade {
private SubSystemA subSystemA;
public SubSystemAFacade() {
subSystemA = new SubSystemA();
}
// 提供給客戶端的接口
public void operation() {
subSystemA.operationA();
}
}
// 子系統(tǒng)B的門面類
class SubSystemBFacade {
private SubSystemB subSystemB;
public SubSystemBFacade() {
subSystemB = new SubSystemB();
}
// 提供給客戶端的接口
public void operation() {
subSystemB.operationB();
}
}
通過(guò)上述優(yōu)化實(shí)現(xiàn)方式,我們能夠靈活地應(yīng)對(duì)不同的需求和場(chǎng)景,提高了系統(tǒng)的可擴(kuò)展性和維護(hù)性。
門面嵌套
假設(shè)我們有一個(gè)文件處理系統(tǒng),其中包括三個(gè)子系統(tǒng):文件讀取(FileReader)、文件寫入(FileWriter)和文件壓縮(FileCompressor)。
現(xiàn)在有兩個(gè)模塊來(lái)訪問(wèn)該子系統(tǒng):通用模塊(GeneralModule)可以完整地訪問(wèn)所有業(yè)務(wù)邏輯,而受限模塊(RestrictedModule)只能訪問(wèn)文件讀取操作。
在這種情況下,我們可以在門面外再嵌套門面來(lái)解決接口權(quán)限問(wèn)題,以供不同的模塊訪問(wèn)。
// 子系統(tǒng):文件讀取
class FileReader {
public void read(String filePath) {
System.out.println("讀取文件:" + filePath);
// 具體的讀取邏輯...
}
}
// 子系統(tǒng):文件寫入
class FileWriter {
public void write(String filePath, String content) {
System.out.println("寫入文件:" + filePath);
// 具體的寫入邏輯...
}
}
// 子系統(tǒng):文件壓縮
class FileCompressor {
public void compress(String filePath, String destinationPath) {
System.out.println("壓縮文件:" + filePath + " -> " + destinationPath);
// 具體的壓縮邏輯...
}
}
// 通用模塊門面
class GeneralFacade {
private FileReader fileReader;
private FileWriter fileWriter;
private FileCompressor fileCompressor;
public GeneralFacade() {
this.fileReader = new FileReader();
this.fileWriter = new FileWriter();
this.fileCompressor = new FileCompressor();
}
public void processFile(String filePath, String content, String destinationPath) {
fileReader.read(filePath);
fileWriter.write(filePath, content);
fileCompressor.compress(filePath, destinationPath);
}
public void read(String filePath) {
fileReader.read(filePath);
}
}
// 受限模塊門面
class RestrictedFacade {
private GeneralFacade generalFacade = new GeneralFacade();
public void readRestrictedFile(String filePath) {
generalFacade.read(filePath);
}
}
// 客戶端代碼
public class Client {
public static void main(String[] args) {
GeneralFacade generalFacade = new GeneralFacade();
generalFacade.processFile("file.txt", "Hello World!", "compressed.zip");
RestrictedFacade restrictedFacade = new RestrictedFacade();
restrictedFacade.readRestrictedFile("file.txt");
}
}
在上述示例中,我們使用了兩個(gè)不同的門面:GeneralFacade和RestrictedFacade。GeneralFacade提供了完整的訪問(wèn)子系統(tǒng)的方法(processFile),而RestrictedFacade僅提供了受限的文件讀取方法(readRestrictedFile)。
通過(guò)不同的門面對(duì)象,通用模塊可以訪問(wèn)所有子系統(tǒng)功能,而受限模塊只能訪問(wèn)特定的子系統(tǒng)功能。
總結(jié)
通過(guò)使用門面模式,我們可以簡(jiǎn)化復(fù)雜系統(tǒng)的調(diào)用過(guò)程,提高代碼的可維護(hù)性和可讀性。門面模式將子系統(tǒng)進(jìn)行封裝,并提供一個(gè)簡(jiǎn)單的接口給客戶端,隱藏了子系統(tǒng)的復(fù)雜性,同時(shí)解耦了客戶端與子系統(tǒng)之間的依賴關(guān)系。