概述

今天要說的外觀模式是一個相對簡單的設計模式，而且在日常的開發中，可能你也會時常使用它，只是你可能并未想過這是一個設計模式。本文會從一些實例著手，來對本文要說明的外觀模式進行盡可能全面的講解。希望于你有益。

引言

這里插入一條引言的目的是讓你回想一下，在你日常開發中何時用到了外觀模式。

可能你的 boss 會這樣安排你一個任務。這可能是一個核心模塊，模塊會有它的一個功能，只是你的 boss 可能只想要你提供一個給他調用的接口。他會這么跟你說：嗨，小明，我們現在的這個系統里需要一個核心的功能 P0，它就交給你實現吧。你只要給我可以調用的接口就好了，你代碼的內部邏輯我不需要知道的。去做吧。

如果你時常被安排這樣的任務，我想你應該已經掌握外觀模式了。

定義

外觀模式提供了一個統一的接口，用來訪問子系統中的一群接口。外觀模式定義一個高層接口，讓子系統更容易使用。

目錄

版權說明

著作權歸作者所有。

商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

本文作者：Q-WHai

發表日期： 2016年6月6日

本文鏈接：http://blog.csdn.net/lemon_tree12138/article/details/51592617

來源：CSDN

更多內容：分類 >> 設計模式

非外觀模式

這里我就使用《大話設計模式》書中的例子了，感覺這個例子還是挺形象的。現在假設你是一個股民(只是博主不炒股，也不知道這里會不會有說得不對的地方，如果有你就當沒看見吧。。^_^)，你想做一些理財活動。你看中了兩支股票、一支國債和一支房地產。

如果讓你現在來編寫這份代碼，你的代碼框架可能會像下面的這幅類圖：

這里只列舉了股票的代碼，是因為其他理財活動的邏輯與股票的邏輯是一致的。冗余的代碼除了占地方之外并沒有再多的好處了。

StockA.java

public class StockA {

private int stockCount = 0;

public void sell(int count){

stockCount -= count;

System.out.println("賣了" + count + "支 A 股票");

}

public void buy(int count){

stockCount += count;

System.out.println("買了" + count + "支 A 股票");

}

public int getStockCount() {

return stockCount;

}

}

下面的代碼是處理理財者的，對于一個簡單地買進買出邏輯，理財者都要花費這么多的代碼處理，實在是折磨人嘛。

Investors.java

public class Investors {

public static void main(String[] args) {

StockA stockA = new StockA();

StockB stockB = new StockB();

NationalDebt debt = new NationalDebt();

RealEstate estate = new RealEstate();

stockA.buy(100);

stockB.buy(200);

debt.buy(150);

estate.buy(120);

stockA.sell(100);

stockB.sell(200);

debt.sell(150);

estate.sell(120);

}

}

上面說的這些是在沒有使用外觀模式的情況下編寫的代碼。也就是說下面要說的外觀模式可以讓代碼更加簡單明了了。

外觀模式

在上面的非外觀模式中，我們看到了一些不是很友好的代碼邏輯。而外觀模式可以基于更高層次的封裝，從而達到對調用者更加透明。下面是修改后的外觀模式類圖：

FundFacade.java

public class FundFacade {

private StockA stockA = null;

private StockB stockB = null;

private NationalDebt debt = null;

private RealEstate estate = null;

public FundFacade() {

stockA = new StockA();

stockB = new StockB();

debt = new NationalDebt();

estate = new RealEstate();

}

public void buyAll(int count) {

stockA.buy(count);

stockB.buy(count);

debt.buy(count);

estate.buy(count);

}

public void sellAll(int count) {

stockA.sell(count);

stockB.sell(count);

debt.sell(count);

estate.sell(count);

}

public void buyStockA(int count) {

stockA.buy(count);

}

public void sellNationalDebt(int count) {

debt.sell(count);

}

}

上面的代碼則是外觀的核心類：FundFacade。在理財系統中的所有操作都可以通過這個類來實現。你通過這個類可以很方便地實現對股票、國債、房地產等理財項目的操作，而不用關心里面究竟是怎么處理的。這是對用戶來說是一件好事，不是嗎？

來看看用戶的操作吧(當然上面圖類已經反映了絕大部分效果了)，這是用戶的代碼邏輯：

Investors.java

public class Investors {

public static void main(String[] args) {

FundFacade facade = new FundFacade();

facade.buyAll(120);

facade.buyStockA(50);

facade.sellAll(80);

}

}

看看，用戶只要告訴 FundFacade 類，買入什么、賣出什么、買多少、賣多少，就可以達到目的。實在是太方便了。

看看股票 A 的代碼吧，其實它并什么實質性的變化。這也是外觀模式的魅力所在，它不用你去修改原來子系統的代碼，只要做一件事，構建更高層次的封裝。當然，這里我做了一些簡單地修改，StockA 的訪問權限。既然要對用戶透明，那么我的子系統就沒有必要再對用戶開放了，不是嗎？因為我們已經有專業的外交官—— FundFacade。

StockA.java

class StockA {

private int stockCount = 0;

void sell(int count){

stockCount -= count;

System.out.println("賣了" + count + "支 A 股票");

}

void buy(int count){

stockCount += count;

System.out.println("買了" + count + "支 A 股票");

}

int getStockCount() {

return stockCount;

}

}

外觀模式是一個相對簡單的設計模式，你可以很輕松地掌握并使用它。只是我想說，外觀模式也會存在一定的局限性。相信你已經發現了。

由于我們把對于子系統所有的操作都交給了 FundFacade 類來處理，所以我們就受到了 FundFacade 類的約束了。比如上面的 FundFacade 類中并沒有實現單獨對 StockB 的操作，那么我們就不能單獨對 StockB 進行操作了，除非你在 FundFacade 類中封裝一個對 StockB 操作的接口。

外觀模式的應用

上面的描述中我們不僅知道了如何使用外觀模式，也了解了外觀模式的局限，所以我們應該站在客觀的立場，有選擇性地使用它。這里說一個我在工作中使用外觀模式的例子吧。

目前項目的老大讓我去實現一個系統中的某一個模塊，我想這應該是一個核心模塊吧。這個模塊的功能是，檢查一個文件夾下的所有文件是否包含了敏感信息。而這個模塊中會有很多小的子模塊(當然老大并不會關心這些子模塊做的事情)，比如 AC 自動機的模式匹配、壓縮文件的全自動解壓、各種格式文件(doc/xls/ppt/zip/eml/rtf/pdf 等等，絕大部分的文件格式基本都在吧)、日志系統等等。

我不可能去跟老大說，你要完成的功能是要先去干嘛、再去干嘛、再去干嘛、再去干嘛… …

哦，天啦。煩死了，你能對它封裝一下嗎？(當然，這些只是我的心理活動。事實上，我還沒有讓老大說明我的設計過程)

封裝過后，我只要告訴老大，去調用這個類的這個方法就 ok 了。這樣老大那邊就不用操心里面的邏輯了，雖然如果出了錯就是你的責任，可那也本該就 是你的責任啊。哈哈。。。

好了，扯蛋就到這里。不管是上面正兒八經地模式詳解，還是下面的胡說八道，我都希望它可以讓你充分了解本文這個設計模式，學習并合理使用它。

Ref

總結

以上是生活随笔為你收集整理的java 外观模式类图_Java 设计模式——外观模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。