PS：首先我們要帶着問題讀文章
- 什么是設計模式
- 為什么要用設計模式
- 使用設計模式有什么好處
設計模式是一套被反復使用的、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。
該篇文章主要寫的是（介紹沒有順序）
- 適配器設計模式
- 單例設計模式
- 靜態代理設計模式
- 簡單工廠設計模式
1：適配器設計模式
意圖：將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。
主要解決：主要解決在軟件系統中，常常要將一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能滿足的。
官方給出：
優點： 1、可以讓任何兩個沒有關聯的類一起運行。 2、提高了類的復用。 3、增加了類的透明度。 4、靈活性好。
缺點： 1、過多地使用適配器，會讓系統非常零亂，不易整體進行把握。比如，明明看到調用的是 A 接口，其實內部被適配成了 B 接口的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是很有必要，可以不使用適配器，而是直接對系統進行重構。 2.由於 JAVA 至多繼承一個類，所以至多只能適配一個適配者類，而且目標類必須是抽象類。
示例：這里我簡單寫一個關於兩個接口的例子，來調用里面的方法來看看效果這兩個接口我們可以理解成充電器，一個是蘋果lighting口，一個安卓充電器，我們都知道這兩個充電器接口是不一樣的，但是淘寶上有賣轉換頭的，可以在蘋果頭上套一個轉換器就可以沖安卓手機里，這中間的轉換頭就是我們所說的適配器，我再配張圖（中間一頭是方形一頭是圓形就是適配器）
好，廢話不多說，開始
（1）首先寫一個A蘋果接口，一個B安卓接口然后實現該接口里的方法，開始工作
//實現A
class PowerA {
public void workA(){}
}
class PowerAiml extends PowerA{
public void workA(){
System.out.println("我是A，我要開始工作了");
}
}
//實現B
class PowerB {
public void workB(){}
}
class PowerBiml extends PowerB{
public void workB(){
System.out.println("我是B，我要開始工作了");
}
}
（2）寫一個方法只有A（蘋果）接口可以用。
public static void work(PowerA a){
System.out.println("開始-------");
a.workA();
System.out.println("結束-------");
}
（3）調用查看效果
PowerA pa=new PowerAiml(); work(pa);
這樣使用是沒有任何問題的，因為參數就是PowerA a，只要是傳入實現PowerA接口的class都可以調用該方法，但是，問題來了，如果我想讓使用PowerB怎么辦呢，有兩個方法，一個是再寫一個work2（PowerB b），另一個是用適配器的方法，顯然第一種方法對於這個例子是最簡單的，但是在一個軟件編寫的過程中不光是這一點代碼，代碼有很多，難道都要再寫方法嗎，那樣子就太麻煩了，現在就用適配器的方法
（4）適配器
想要使用A方法，就要偽裝成A，把適配器實現PowerA
//適配器：
class Adapter1 extends PowerA{
public PowerB b;
public Adapter1(PowerB b){
this.b=b;
}
//當調用A的時候，就自動調用B里的方法。
public void workA(){
b.workB();
}
}
調用的時候是，一頭與B關聯，一頭與A關聯
PowerB b=new PowerBiml(); Adapter1 adapter=new Adapter1(b); work(adapter);
解釋一下：在Adapter1中傳入的b，然后把adapter傳入work，雖然調用的都是workA，但是關鍵來了，在workA方法中又調用了b.workB()；就是這么一個思路。
這是一個非常簡單的例子，在開發過程中，真正要用到適配器要比這個看似復雜點，原理都是一樣的，畢竟小孩子的性格是天真的，大人的性格就變化莫測了。
2：代理設計模式
意圖：為其他對象提供一種代理以控制對這個對象的訪問。
主要解決：在直接訪問對象時帶來的問題，比如說：要訪問的對象在遠程的機器上。在面向對象系統中，有些對象由於某些原因（比如對象創建開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問），直接訪問會給使用者或者系統結構帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。
何時使用：想在訪問一個類時做一些控制。
如何解決：增加中間層。
靜態代理模式，說白了就是委托，將所有的事情都委托給別人幫你完成，你所要做的，就是給代理一些東西，接下來所有的事情都是代理幫你完成，你完全不用去關心內部是如何實現的。舉個例子簡單的說一下，一個人買衣服，可以去實體店也可以去網上，買火車票的時候，你就知道售票員就會給你 你想要的票，而且你只需要給他錢和身份證以及地點就可以了，他會經過處理，最后把票給你，他就處於一個代理模式。下面我簡單寫一個例子
比如說我只想要水，我就給你送水的公司打電話讓他們送一桶水，然后我就在家等着就可以，在這期間誰送水，怎么送，需要多久，什么樣的水等一切我都不需要知道，這都被送水公司代理了。OK
（1）先寫一個要水的類和接口
class Action{
public void work(){}
}
class MyAction extends Action{
public void work(){
//在這期間可能會有我不想做的事，但還是要有，比如說一共耗時，打水結果要的是水，但必需要拿水桶等。
//這些東西都是可以讓代理給做了，
System.out.println("獲得水");
}
}
（2）寫代理類
如果不寫代理類的話，也可以直接調用work方法，但是就相當於自己去搬水，而不是用代理。
/**
* 代理類
* 控制，在方法前或后所要做的類。
* */
class DaiLiAction extends Action{
private Action action;
public DaiLiAction(Action action){
this.action=action;
}
public void work(){
System.out.println("我是送水公司");
System.out.println("代理正在處理中。。。");
System.out.println("代理處理完了返回給你結果");
action.work();
}
}
（3）調用即可
Action ac=new MyAction(); //把對象給代理類，工作是由代理完成。 DaiLiAction dai=new DaiLiAction(ac); dai.work();
3：單例設計模式
http://www.cnblogs.com/cmusketeer/p/8016550.html
4:簡單工廠設計模式
意圖：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。
主要解決：主要解決接口選擇的問題。
何時使用：我們明確地計划不同條件下創建不同實例時。
如何解決：讓其子類實現工廠接口，返回的也是一個抽象的產品。
/**
* 工廠接口
* */
interface Factory1{
public void create();
}
/**
* 手機
* */
class Phone implements Factory1{
@Override
public void create() {
System.out.println("我是造--手機--的");
}
}
/**
* 電腦
* */
class Computer implements Factory1{
@Override
public void create() {
System.out.println("我是造--電腦--的");
}
}
（2）創建工廠控制類FactoryControl
/**
* 工廠控制類
* */
class FactoryControl{
public static Factory1 getGood(String good){
if(good.equalsIgnoreCase("phone")){
return new Phone();
}else if(good.equalsIgnoreCase("computer")){
return new Computer();
}
return null;
}
}
(3)調用和效果
Factory1 factory=FactoryControl.getGood("phone");
factory.create();
factory=FactoryControl.getGood("computer");
factory.create();
當然，也可以不經過FactoryControl（工廠類）,也是可以調用的，但是如果是大工程，使用該模式可以降低使用者和被使用者之間的依賴。這里就算你傳入一個耳機，沒有這個功能，它也不會報錯，返回null。
好了，下一篇就會繼續寫剩下的19個設計模式，例子都是簡單易懂的，只要理解了，慢慢的再寫復雜的代碼就輕松了，只要有了思想，寫代碼就簡單了，可以告別有能力但總覺得無處施展的尷尬。