本系列文章将整理到我在GitHub上的《Java面試指南》倉庫，更多精彩内容請到我的倉庫裡檢視
https://github.com/h2pl/Java-Tutorial
喜歡的話麻煩點下Star、fork哈
文章也将發表在我的個人部落格，閱讀體驗更佳：
www.how2playlife.com
本文是微信公衆号【Java技術江湖】的《夯實Java基礎系列博文》其中一篇，本文部分内容來源于網絡，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格内容，引用其中了一些比較好的部落格文章，如有侵權，請聯系作者。
該系列博文會告訴你如何從入門到進階，一步步地學習Java基礎知識，并上手進行實戰，接着了解每個Java知識點背後的實作原理，更完整地了解整個Java技術體系，形成自己的知識架構。為了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。
如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公衆号【Java技術江湖】聯系作者，歡迎你參與本系列博文的創作和修訂
設計模式作為工作學習中的枕邊書，卻時常處于勤說不用的尴尬境地，也不是我們時常忘記，隻是一直沒有記憶。
今天，螃蟹在IT學習者網站就設計模式的内在價值做一番探讨，并以spring為例進行講解，隻有領略了其設計的思想理念，才能在工作學習中運用到“無形”。
Spring作為業界的經典架構，無論是在架構設計方面，還是在代碼編寫方面，都堪稱行内典範。好了，話不多說，開始今天的内容。
spring中常用的設計模式達到九種，我們舉例說明：
第一種：簡單工廠
又叫做靜态工廠方法（StaticFactory Method）模式，但不屬于23種GOF設計模式之一。
簡單工廠模式的實質是由一個工廠類根據傳入的參數，動态決定應該建立哪一個産品類。
spring中的BeanFactory就是簡單工廠模式的展現，根據傳入一個唯一的辨別來獲得bean對象，但是否是在傳入參數後建立還是傳入參數前建立這個要根據具體情況來定。如下配置，就是在 HelloItxxz 類中建立一個 itxxzBean。
<beans>
<bean id="singletonBean" >
<constructor-arg>
<value>Hello! 這是singletonBean!value>
</constructor-arg>
</ bean>
<bean id="itxxzBean"
singleton="false">
<constructor-arg>
<value>Hello! 這是itxxzBean! value>
</constructor-arg>
</bean>
</beans>
第二種：工廠方法（Factory Method）
通常由應用程式直接使用new建立新的對象，為了将對象的建立和使用相分離，采用工廠模式,即應用程式将對象的建立及初始化職責交給工廠對象。
一般情況下,應用程式有自己的工廠對象來建立bean.如果将應用程式自己的工廠對象交給Spring管理,那麼Spring管理的就不是普通的bean,而是工廠Bean。
螃蟹就以工廠方法中的靜态方法為例講解一下：
import java.util.Random;
public class StaticFactoryBean {
public static Integer createRandom() {
return new Integer(new Random().nextInt());
}
}
建一個config.xm配置檔案，将其納入Spring容器來管理,需要通過factory-method指定靜态方法名稱
<bean id="random"
factory-method="createRandom" //createRandom方法必須是static的,才能找到 scope="prototype"
/>
測試:
public static void main(String[] args) {
//調用getBean()時,傳回随機數.如果沒有指定factory-method,會傳回StaticFactoryBean的執行個體,即傳回工廠Bean的執行個體 XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml")); System.out.println("我是IT學習者建立的執行個體:"+factory.getBean("random").toString());
}
第三種：單例模式（Singleton）
保證一個類僅有一個執行個體，并提供一個通路它的全局通路點。
spring中的單例模式完成了後半句話，即提供了全局的通路點BeanFactory。但沒有從構造器級别去控制單例，這是因為spring管理的是是任意的java對象。
核心提示點：Spring下預設的bean均為singleton，可以通過singleton=“true|false” 或者 scope=“？”來指定
第四種：擴充卡（Adapter）
在Spring的Aop中，使用的Advice（通知）來增強被代理類的功能。Spring實作這一AOP功能的原理就使用代理模式（1、JDK動态代理。2、CGLib位元組碼生成技術代理。）對類進行方法級别的切面增強，即，生成被代理類的代理類， 并在代理類的方法前，設定攔截器，通過執行攔截器重的内容增強了代理方法的功能，實作的面向切面程式設計。
Adapter類接口：
public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
MethodInterceptor getInterceptor(Advisor advisor);
} **MethodBeforeAdviceAdapter類**，Adapter
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
public boolean supportsAdvice(Advice advice) {
return (advice instanceof MethodBeforeAdvice);
}
public MethodInterceptor getInterceptor(Advisor advisor) {
MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
return new MethodBeforeAdviceInterceptor(advice);
}
}
第五種：包裝器（Decorator）
在我們的項目中遇到這樣一個問題：我們的項目需要連接配接多個資料庫，而且不同的客戶在每次通路中根據需要會去通路不同的資料庫。我們以往在spring和hibernate架構中總是配置一個資料源，因而sessionFactory的dataSource屬性總是指向這個資料源并且恒定不變，所有DAO在使用sessionFactory的時候都是通過這個資料源通路資料庫。
但是現在，由于項目的需要，我們的DAO在通路sessionFactory的時候都不得不在多個資料源中不斷切換，問題就出現了：如何讓sessionFactory在執行資料持久化的時候，根據客戶的需求能夠動态切換不同的資料源？我們能不能在spring的架構下通過少量修改得到解決？是否有什麼設計模式可以利用呢？
首先想到在spring的applicationContext中配置所有的dataSource。這些dataSource可能是各種不同類型的，比如不同的資料庫：Oracle、SQL Server、MySQL等，也可能是不同的資料源：比如apache 提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然後sessionFactory根據客戶的每次請求，将dataSource屬性設定成不同的資料源，以到達切換資料源的目的。
spring中用到的包裝器模式在類名上有兩種表現：一種是類名中含有Wrapper，另一種是類名中含有Decorator。基本上都是動态地給一個對象添加一些額外的職責。
第六種：代理（Proxy）
為其他對象提供一種代理以控制對這個對象的通路。 從結構上來看和Decorator模式類似，但Proxy是控制，更像是一種對功能的限制，而Decorator是增加職責。
spring的Proxy模式在aop中有展現，比如JdkDynamicAopProxy和Cglib2AopProxy。
第七種：觀察者（Observer）
定義對象間的一種一對多的依賴關系，當一個對象的狀态發生改變時，所有依賴于它的對象都得到通知并被自動更新。
spring中Observer模式常用的地方是listener的實作。如ApplicationListener。
第八種：政策（Strategy）
定義一系列的算法，把它們一個個封裝起來，并且使它們可互相替換。本模式使得算法可獨立于使用它的客戶而變化。
spring中在執行個體化對象的時候用到Strategy模式
在SimpleInstantiationStrategy中有如下代碼說明了政策模式的使用情況：
第九種：模闆方法（Template Method）
定義一個操作中的算法的骨架，而将一些步驟延遲到子類中。Template Method使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
Template Method模式一般是需要繼承的。這裡想要探讨另一種對Template Method的了解。
spring中的JdbcTemplate，在用這個類時并不想去繼承這個類，因為這個類的方法太多，但是我們還是想用到JdbcTemplate已有的穩定的、公用的資料庫連接配接，那麼我們怎麼辦呢？我們可以把變化的東西抽出來作為一個參數傳入JdbcTemplate的方法中。但是變化的東西是一段代碼，而且這段代碼會用到JdbcTemplate中的變量。
怎麼辦？那我們就用回調對象吧。在這個回調對象中定義一個操縱JdbcTemplate中變量的方法，我們去實作這個方法，就把變化的東西集中到這裡了。然後我們再傳入這個回調對象到JdbcTemplate，進而完成了調用。這可能是Template Method不需要繼承的另一種實作方式吧。
結構型模式
前面建立型模式介紹了建立對象的一些設計模式，這節介紹的結構型模式旨在通過改變代碼結構來達到解耦的目的，使得我們的代碼容易維護和擴充。
代理模式
第一個要介紹的代理模式是最常使用的模式之一了，用一個代理來隐藏具體實作類的實作細節，通常還用于在真實的實作的前後添加一部分邏輯。
既然說是代理，那就要對用戶端隐藏真實實作，由代理來負責用戶端的所有請求。當然，代理隻是個代理，它不會完成實際的業務邏輯，而是一層皮而已，但是對于用戶端來說，它必須表現得就是用戶端需要的真實實作。
了解代理這個詞，這個模式其實就簡單了。
public interface FoodService {
Food makeChicken();
Food makeNoodle();
}
public class FoodServiceImpl implements FoodService {
public Food makeChicken() {
Food f = new Chicken()
f.setChicken("1kg");
f.setSpicy("1g");
f.setSalt("3g");
return f;
}
public Food makeNoodle() {
Food f = new Noodle();
f.setNoodle("500g");
f.setSalt("5g");
return f;
}
}
// 代理要表現得“就像是”真實實作類，是以需要實作 FoodService
public class FoodServiceProxy implements FoodService {
// 内部一定要有一個真實的實作類，當然也可以通過構造方法注入
private FoodService foodService = new FoodServiceImpl();
public Food makeChicken() {
System.out.println("我們馬上要開始制作雞肉了");
// 如果我們定義這句為核心代碼的話，那麼，核心代碼是真實實作類做的，
// 代理隻是在核心代碼前後做些“無足輕重”的事情
Food food = foodService.makeChicken();
System.out.println("雞肉制作完成啦，加點胡椒粉"); // 增強
food.addCondiment("pepper");
return food;
}
public Food makeNoodle() {
System.out.println("準備制作拉面~");
Food food = foodService.makeNoodle();
System.out.println("制作完成啦")
return food;
}
}
用戶端調用，注意，我們要用代理來執行個體化接口：
// 這裡用代理類來執行個體化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();
我們發現沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強”。在面向切面程式設計中，算了還是不要吹捧這個名詞了，在 AOP 中，其實就是動态代理的過程。比如 Spring 中，我們自己不定義代理類，但是 Spring 會幫我們動态來定義代理，然後把我們定義在 @Before、@After、@Around 中的代碼邏輯動态添加到代理中。
說到動态代理，又可以展開說 …… Spring 中實作動态代理有兩種，一種是如果我們的類定義了接口，如 UserService 接口和 UserServiceImpl 實作，那麼采用 JDK 的動态代理，感興趣的讀者可以去看看 java.lang.reflect.Proxy 類的源碼；另一種是我們自己沒有定義接口的，Spring 會采用 CGLIB 進行動态代理，它是一個 jar 包，性能還不錯。
擴充卡模式
說完代理模式，說擴充卡模式，是因為它們很相似，這裡可以做個比較。
擴充卡模式做的就是，有一個接口需要實作，但是我們現成的對象都不滿足，需要加一層擴充卡來進行适配。
擴充卡模式總體來說分三種：預設擴充卡模式、對象擴充卡模式、類擴充卡模式。先不急着厘清楚這幾個，先看看例子再說。
預設擴充卡模式
首先，我們先看看最簡單的擴充卡模式預設擴充卡模式(Default Adapter)是怎麼樣的。
我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對檔案或檔案夾進行監控，一旦發生了對應的操作，就會觸發相應的方法。
public interface FileAlterationListener {
void onStart(final FileAlterationObserver observer);
void onDirectoryCreate(final File directory);
void onDirectoryChange(final File directory);
void onDirectoryDelete(final File directory);
void onFileCreate(final File file);
void onFileChange(final File file);
void onFileDelete(final File file);
void onStop(final FileAlterationObserver observer);
}
此接口的一大問題是抽象方法太多了，如果我們要用這個接口，意味着我們要實作每一個抽象方法，如果我們隻是想要監控檔案夾中的檔案建立和檔案删除事件，可是我們還是不得不實作所有的方法，很明顯，這不是我們想要的。
是以，我們需要下面的一個擴充卡，它用于實作上面的接口，但是所有的方法都是空方法，這樣，我們就可以轉而定義自己的類來繼承下面這個類即可。
public class FileAlterationListenerAdaptor implements FileAlterationListener {
public void onStart(final FileAlterationObserver observer) {
}
public void onDirectoryCreate(final File directory) {
}
public void onDirectoryChange(final File directory) {
}
public void onDirectoryDelete(final File directory) {
}
public void onFileCreate(final File file) {
}
public void onFileChange(final File file) {
}
public void onFileDelete(final File file) {
}
public void onStop(final FileAlterationObserver observer) {
}
}
比如我們可以定義以下類，我們僅僅需要實作我們想實作的方法就可以了：
public class FileMonitor extends FileAlterationListenerAdaptor {
public void onFileCreate(final File file) {
// 檔案建立
doSomething();
}
public void onFileDelete(final File file) {
// 檔案删除
doSomething();
}
}
當然，上面說的隻是擴充卡模式的其中一種，也是最簡單的一種，無需多言。下面，再介紹“正統的”擴充卡模式。
對象擴充卡模式
來看一個《Head First 設計模式》中的一個例子，我稍微修改了一下，看看怎麼将雞适配成鴨，這樣雞也能當鴨來用。因為，現在鴨這個接口，我們沒有合适的實作類可以用，是以需要擴充卡。
public interface Duck {
public void quack(); // 鴨的呱呱叫
public void fly(); // 飛
}
public interface Cock {
public void gobble(); // 雞的咕咕叫
public void fly(); // 飛
}
public class WildCock implements Cock {
public void gobble() {
System.out.println("咕咕叫");
}
public void fly() {
System.out.println("雞也會飛哦");
}
}
鴨接口有 fly() 和 quare() 兩個方法，雞 Cock 如果要冒充鴨，fly() 方法是現成的，但是雞不會鴨的呱呱叫，沒有 quack() 方法。這個時候就需要适配了：
// 毫無疑問，首先，這個擴充卡肯定需要 implements Duck，這樣才能當做鴨來用
public class CockAdapter implements Duck {
Cock cock;
// 構造方法中需要一個雞的執行個體，此類就是将這隻雞适配成鴨來用
public CockAdapter(Cock cock) {
this.cock = cock;
}
// 實作鴨的呱呱叫方法
@Override
public void quack() {
// 内部其實是一隻雞的咕咕叫
cock.gobble();
}
@Override
public void fly() {
cock.fly();
}
}
用戶端調用很簡單了：
public static void main(String[] args) {
// 有一隻野雞
Cock wildCock = new WildCock();
// 成功将野雞适配成鴨
Duck duck = new CockAdapter(wildCock);
...
}
到這裡，大家也就知道了擴充卡模式是怎麼回事了。無非是我們需要一隻鴨，但是我們隻有一隻雞，這個時候就需要定義一個擴充卡，由這個擴充卡來充當鴨，但是擴充卡裡面的方法還是由雞來實作的。
我們用一個圖來簡單說明下：
上圖應該還是很容易了解的，我就不做更多的解釋了。下面，我們看看類适配模式怎麼樣的。
類擴充卡模式
廢話少說，直接上圖：
看到這個圖，大家應該很容易了解的吧，通過繼承的方法，擴充卡自動獲得了所需要的大部分方法。這個時候，用戶端使用更加簡單，直接
Target t = new SomeAdapter();
就可以了。
擴充卡模式總結
- 類适配和對象适配的異同
> 一個采用繼承，一個采用組合； > > 類适配屬于靜态實作，對象适配屬于組合的動态實作，對象适配需要多執行個體化一個對象。 > > 總體來說，對象适配用得比較多。 - 擴充卡模式和代理模式的異同
比較這兩種模式，其實是比較對象擴充卡模式和代理模式，在代碼結構上，它們很相似，都需要一個具體的實作類的執行個體。但是它們的目的不一樣，代理模式做的是增強原方法的活；擴充卡做的是适配的活，為的是提供“把雞包裝成鴨，然後當做鴨來使用”，而雞和鴨它們之間原本沒有繼承關系。
橋梁模式
了解橋梁模式，其實就是了解代碼抽象和解耦。
我們首先需要一個橋梁，它是一個接口，定義提供的接口方法。
public interface DrawAPI {
public void draw(int radius, int x, int y);
}
然後是一系列實作類：
public class RedPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用紅色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class GreenPen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用綠色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
public class BluePen implements DrawAPI {
@Override
public void draw(int radius, int x, int y) {
System.out.println("用藍色筆畫圖，radius:" + radius + ", x:" + x + ", y:" + y);
}
}
定義一個抽象類，此類的實作類都需要使用 DrawAPI：
public abstract class Shape {
protected DrawAPI drawAPI;
protected Shape(DrawAPI drawAPI){
this.drawAPI = drawAPI;
}
public abstract void draw();
}
定義抽象類的子類：
// 圓形
public class Circle extends Shape {
private int radius;
public Circle(int radius, DrawAPI drawAPI) {
super(drawAPI);
this.radius = radius;
}
public void draw() {
drawAPI.draw(radius, 0, 0);
}
}
// 長方形
public class Rectangle extends Shape {
private int x;
private int y;
public Rectangle(int x, int y, DrawAPI drawAPI) {
super(drawAPI);
this.x = x;
this.y = y;
}
public void draw() {
drawAPI.draw(0, x, y);
}
}
最後，我們來看用戶端示範：
public static void main(String[] args) {
Shape greenCircle = new Circle(10, new GreenPen());
Shape redRectangle = new Rectangle(4, 8, new RedPen());
greenCircle.draw();
redRectangle.draw();
}
可能大家看上面一步步還不是特别清晰，我把所有的東西整合到一張圖上：
這回大家應該就知道抽象在哪裡，怎麼解耦了吧。橋梁模式的優點也是顯而易見的，就是非常容易進行擴充。
本節引用了 這裡 的例子，并對其進行了修改。
裝飾模式
要把裝飾模式說清楚明白，不是件容易的事情。也許讀者知道 Java IO 中的幾個類是典型的裝飾模式的應用，但是讀者不一定清楚其中的關系，也許看完就忘了，希望看完這節後，讀者可以對其有更深的感悟。
首先，我們先看一個簡單的圖，看這個圖的時候，了解下層次結構就可以了：
我們來說說裝飾模式的出發點，從圖中可以看到，接口
Component
其實已經有了
ConcreteComponentA
和
ConcreteComponentB
兩個實作類了，但是，如果我們要增強這兩個實作類的話，我們就可以采用裝飾模式，用具體的裝飾器來裝飾實作類，以達到增強的目的。
從名字來簡單解釋下裝飾器。既然說是裝飾，那麼往往就是添加小功能這種，而且，我們要滿足可以添加多個小功能。最簡單的，代理模式就可以實作功能的增強，但是代理不容易實作多個功能的增強，當然你可以說用代理包裝代理的方式，但是那樣的話代碼就複雜了。
首先明白一些簡單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator_ 都可以作為 Component 來使用，因為它們都實作了 Component 中的所有接口。它們和 Component 實作類 ConcreteComponent_ 的差別是，它們隻是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都隻是在具體的實作中加了層皮來裝飾而已。
注意這段話中混雜在各個名詞中的 Component 和 Decorator，别搞混了。
下面來看看一個例子，先把裝飾模式弄清楚，然後再介紹下 java io 中的裝飾模式的應用。
最近大街上流行起來了“快樂檸檬”，我們把快樂檸檬的飲料分為三類：紅茶、綠茶、咖啡，在這三大類的基礎上，又增加了許多的口味，什麼金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很長的菜單，但是仔細看下，其實原料也沒幾樣，但是可以搭配出很多組合，如果顧客需要，很多沒出現在菜單中的飲料他們也是可以做的。
在這個例子中，紅茶、綠茶、咖啡是最基礎的飲料，其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當然，在開發中，我們确實可以像門店一樣，開發這些類：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是，很快我們就發現，這樣子幹肯定是不行的，這會導緻我們需要組合出所有的可能，而且如果客人需要在紅茶中加雙份檸檬怎麼辦？三份檸檬怎麼辦？萬一有個變态要四份檸檬，是以這種做法是給自己找加班的。
不說廢話了，上代碼。
首先，定義飲料抽象基類：
public abstract class Beverage {
// 傳回描述
public abstract String getDescription();
// 傳回價格
public abstract double cost();
}
然後是三個基礎飲料實作類，紅茶、綠茶和咖啡：
public class BlackTea extends Beverage {
public String getDescription() {
return "紅茶";
}
public double cost() {
return 10;
}
}
public class GreenTea extends Beverage {
public String getDescription() {
return "綠茶";
}
public double cost() {
return 11;
}
}
...// 咖啡省略
定義調料，也就是裝飾者的基類，此類必須繼承自 Beverage：
// 調料
public abstract class Condiment extends Beverage {
}
然後我們來定義檸檬、芒果等具體的調料，它們屬于裝飾者，毫無疑問，這些調料肯定都需要繼承 Condiment 類：
public class Lemon extends Condiment {
private Beverage bevarage;
// 這裡很關鍵，需要傳入具體的飲料，如需要傳入沒有被裝飾的紅茶或綠茶，
// 當然也可以傳入已經裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
public Lemon(Beverage bevarage) {
this.bevarage = bevarage;
}
public String getDescription() {
// 裝飾
return bevarage.getDescription() + ", 加檸檬";
}
public double cost() {
// 裝飾
return beverage.cost() + 2; // 加檸檬需要 2 元
}
}
public class Mango extends Condiment {
private Beverage bevarage;
public Mango(Beverage bevarage) {
this.bevarage = bevarage;
}
public String getDescription() {
return bevarage.getDescription() + ", 加芒果";
}
public double cost() {
return beverage.cost() + 3; // 加芒果需要 3 元
}
}
...// 給每一種調料都加一個類
看用戶端調用：
public static void main(String[] args) {
// 首先，我們需要一個基礎飲料，紅茶、綠茶或咖啡
Beverage beverage = new GreenTea();
// 開始裝飾
beverage = new Lemon(beverage); // 先加一份檸檬
beverage = new Mongo(beverage); // 再加一份芒果
System.out.println(beverage.getDescription() + " 價格：￥" + beverage.cost());
//"綠茶, 加檸檬, 加芒果 價格：￥16"
}
如果我們需要芒果珍珠雙份檸檬紅茶：
Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
是不是很變态？
看看下圖可能會清晰一些：
到這裡，大家應該已經清楚裝飾模式了吧。
下面，我們再來說說 java IO 中的裝飾模式。看下圖 InputStream 派生出來的部分類：
我們知道 InputStream 代表了輸入流，具體的輸入來源可以是檔案（FileInputStream）、管道（PipedInputStream）、數組（ByteArrayInputStream）等，這些就像前面奶茶的例子中的紅茶、綠茶，屬于基礎輸入流。
FilterInputStream 承接了裝飾模式的關鍵節點，其實作類是一系列裝飾器，比如 BufferedInputStream 代表用緩沖來裝飾，也就使得輸入流具有了緩沖的功能，LineNumberInputStream 代表用行号來裝飾，在操作的時候就可以取得行号了，DataInputStream 的裝飾，使得我們可以從輸入流轉換為 java 中的基本類型值。
當然，在 java IO 中，如果我們使用裝飾器的話，就不太适合面向接口程式設計了，如：
InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
這樣的結果是，InputStream 還是不具有讀取行号的功能，因為讀取行号的方法定義在 LineNumberInputStream 類中。
我們應該像下面這樣使用：
DataInputStream is = new DataInputStream(
new BufferedInputStream(
new FileInputStream("")));
是以說嘛，要找到純的嚴格符合設計模式的代碼還是比較難的。
門面模式
門面模式（也叫外觀模式，Facade Pattern）在許多源碼中有使用，比如 slf4j 就可以了解為是門面模式的應用。這是一個簡單的設計模式，我們直接上代碼再說吧。
首先，我們定義一個接口：
public interface Shape {
void draw();
}
定義幾個實作類：
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Circle::draw()");
}
}
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}
用戶端調用：
public static void main(String[] args) {
// 畫一個圓形
Shape circle = new Circle();
circle.draw();
// 畫一個長方形
Shape rectangle = new Rectangle();
rectangle.draw();
}
以上是我們常寫的代碼，我們需要畫圓就要先執行個體化圓，畫長方形就需要先執行個體化一個長方形，然後再調用相應的 draw() 方法。
下面，我們看看怎麼用門面模式來讓用戶端調用更加友好一些。
我們先定義一個門面：
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
/**
* 下面定義一堆方法，具體應該調用什麼方法，由這個門面來決定
*/
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
看看現在用戶端怎麼調用：
public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();
// 用戶端調用現在更加清晰了
shapeMaker.drawCircle();
shapeMaker.drawRectangle();
shapeMaker.drawSquare();
}
門面模式的優點顯而易見，用戶端不再需要關注執行個體化時應該使用哪個實作類，直接調用門面提供的方法就可以了，因為門面類提供的方法的方法名對于用戶端來說已經很友好了。
組合模式
組合模式用于表示具有層次結構的資料，使得我們對單個對象群組合對象的通路具有一緻性。
直接看一個例子吧，每個員工都有姓名、部門、薪水這些屬性，同時還有下屬員工集合（雖然可能集合為空），而下屬員工和自己的結構是一樣的，也有姓名、部門這些屬性，同時也有他們的下屬員工集合。
public class Employee {
private String name;
private String dept;
private int salary;
private List<Employee> subordinates; // 下屬
public Employee(String name,String dept, int sal) {
this.name = name;
this.dept = dept;
this.salary = sal;
subordinates = new ArrayList<Employee>();
}
public void add(Employee e) {
subordinates.add(e);
}
public void remove(Employee e) {
subordinates.remove(e);
}
public List<Employee> getSubordinates(){
return subordinates;
}
public String toString(){
return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
}
}
通常，這種類需要定義 add(node)、remove(node)、getChildren() 這些方法。
這說的其實就是組合模式，這種簡單的模式我就不做過多介紹了，相信各位讀者也不喜歡看我寫廢話。
享元模式
英文是 Flyweight Pattern，不知道是誰最先翻譯的這個詞，感覺這翻譯真的不好了解，我們試着強行關聯起來吧。Flyweight 是輕量級的意思，享元分開來說就是 共享 元器件，也就是複用已經生成的對象，這種做法當然也就是輕量級的了。
複用對象最簡單的方式是，用一個 HashMap 來存放每次新生成的對象。每次需要一個對象的時候，先到 HashMap 中看看有沒有，如果沒有，再生成新的對象，然後将這個對象放入 HashMap 中。
這種簡單的代碼我就不示範了。
結構型模式總結
前面，我們說了代理模式、擴充卡模式、橋梁模式、裝飾模式、門面模式、組合模式和享元模式。讀者是否可以分别把這幾個模式說清楚了呢？在說到這些模式的時候，心中是否有一個清晰的圖或處理流程在腦海裡呢？
代理模式是做方法增強的，擴充卡模式是把雞包裝成鴨這種用來适配接口的，橋梁模式做到了很好的解耦，裝飾模式從名字上就看得出來，适合于裝飾類或者說是增強類的場景，門面模式的優點是用戶端不需要關心執行個體化過程，隻要調用需要的方法即可，組合模式用于描述具有層次結構的資料，享元模式是為了在特定的場景中緩存已經建立的對象，用于提高性能。
參考文章
轉自
https://javadoop.com/post/design-pattern微信公衆号
個人公衆号：程式員黃小斜
微信公衆号【程式員黃小斜】新生代青年聚集地，程式員成長充電站。作者黃小斜，職業是阿裡程式員，身份是斜杠青年，希望和更多的程式員交朋友，一起進步和成長！專注于分享技術、面試、職場等成長幹貨，這一次，我們一起出發。
關注公衆号後回複“2020”領取我這兩年整理的學習資料，涵蓋自學程式設計、求職面試、算法刷題、Java技術學習、計算機基礎和考研等8000G資料合集。
技術公衆号：Java技術江湖
微信公衆号【Java技術江湖】一位阿裡 Java 工程師的技術小站，專注于 Java 相關技術：SSM、SpringBoot、MySQL、分布式、中間件、叢集、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術幹貨和學習經驗，緻力于Java全棧開發！
關注公衆号後回複“PDF”即可領取200+頁的《Java工程師面試指南》強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點。