一、軟體設計模式的幾種分類：

1.1.  建立型

建立物件時，不再由我們直接例項化物件；而是根據特定場景，由程式來確定建立物件的方式，從而保證更大的效能、更好的架構優勢。建立型模式主要有簡單工廠模式（並不是23種設計模式之一）、工廠方法、抽象工廠模式、單例模式、生成器模式和原型模式。

1.2.  結構型

用於幫助將多個物件組織成更大的結構。結構型模式主要有介面卡模式adapter、橋接模式bridge、組合器模式component、裝飾器模式decorator、門面模式、亨元模式flyweight和代理模式proxy。

1.3.  行為型

用於幫助系統間各物件的通訊，以及如何控制複雜系統中流程。行為型模式主要有命令模式command、直譯器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式state、策略模式、模板模式和訪問者模式。

二、常用的設計模式介紹

2.1.  單例模式(singleton)

      有些時候，允許自由建立某個類的例項沒有意義，還可能造成系統性能下降。如果一個類始終只能建立一個例項，則這個類被稱為單例類，這種模式就被稱為單例模式。

    一般建議單例模式的方法命名為：getInstance()，這個方法的返回型別肯定是單例類的型別了。getInstance方法可以有引數，這些引數可能是建立類例項所需要的引數，當然，大多數情況下是不需要的。

public class Singleton {

    private static Singleton singleton;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (singleton == null) {
            singleton = new Singleton();
        }
        return singleton;
    }
}

優點： 
    1.在單例模式中，活動的單例只有一個例項，對單例類的所有例項化得到的都是相同的一個例項。這樣就 防止其它物件對自己的例項化，確保所有的物件都訪問一個例項 
    2.單例模式具有一定的伸縮性，類自己來控制例項化程序，類就在改變例項化程序上有相應的伸縮性。 
    3.提供了對唯一例項的受控訪問。 
    4.由於在系統記憶體中只存在一個物件，因此可以 節約系統資源，當 需要頻繁建立和銷燬的物件時單例模式無疑可以提高系統的效能。 
    5.允許可變數目的例項。 
    6.避免對共享資源的多重佔用。 
缺點： 

    1.不適用於變化的物件，如果同一型別的物件總是要在不同的用例場景發生變化，單例就會引起資料的錯誤，不能儲存彼此的狀態。 
    2.由於單利模式中沒有抽象層，因此單例類的擴充套件有很大的困難。 
    3.單例類的職責過重，在一定程度上違背了“單一職責原則”。 
    4.濫用單例將帶來一些負面問題，如為了節省資源將資料庫連線池物件設計為的單例類，可能會導致共享連線池物件的程式過多而出現連線池溢位；如果例項化的物件長時間不被利用，系統會認為是垃圾而被回收，這將導致物件狀態的丟失。 
使用注意事項： 
    1.使用時不能用反射模式建立單例，否則會例項化一個新的物件 
    2.使用懶單例模式時注意執行緒安全問題 
    3.單例模式和懶單例模式構造方法都是私有的，因而是不能被繼承的，有些單例模式可以被繼承（如登記式模式） 
適用場景： 
    單例模式只允許建立一個物件，因此節省記憶體，加快物件訪問速度，因此物件需要被公用的場合適合使用，如多個模組使用同一個資料來源連線物件等等。如： 
    1.需要頻繁例項化然後銷燬的物件。 
    2.建立物件時耗時過多或者耗資源過多，但又經常用到的物件。 
    3.有狀態的工具類物件。 
    4.頻繁訪問資料庫或檔案的物件。 
以下都是單例模式的經典使用場景： 
    1.資源共享的情況下，避免由於資源操作時導致的效能或損耗等。如上述中的日誌檔案，應用配置。 
    2.控制資源的情況下，方便資源之間的互相通訊。如執行緒池等。 
應用場景舉例： 
    1.外部資源：每臺計算機有若干個印表機，但只能有一個PrinterSpooler，以避免兩個列印作業同時輸出到印表機。內部資源：大多數軟體都有一個（或多個）屬性檔案存放系統配置，這樣的系統應該有一個物件管理這些屬性檔案 
    2. Windows的TaskManager（工作管理員）就是很典型的單例模式（這個很熟悉吧），想想看，是不是呢，你能開啟兩個windows task manager嗎？ 不信你自己試試看哦~ 
    3. windows的Recycle Bin（回收站）也是典型的單例應用。在整個系統執行過程中，回收站一直維護著僅有的一個例項。 
    4. 網站的計數器，一般也是採用單例模式實現，否則難以同步。 
    5. 應用程式的日誌應用，一般都何用單例模式實現，這一般是由於共享的日誌檔案一直處於開啟狀態，因為只能有一個例項去操作，否則內容不好追加。 
    6. Web應用的配置物件的讀取，一般也應用單例模式，這個是由於配置檔案是共享的資源。 
    7. 資料庫連線池的設計一般也是採用單例模式，因為資料庫連線是一種資料庫資源。資料庫軟體系統中使用資料庫連線池，主要是節省開啟或者關閉資料庫連線所引起的效率損耗，這種效率上的損耗還是非常昂貴的，因為何用單例模式來維護，就可以大大降低這種損耗。 
    8. 多執行緒的執行緒池的設計一般也是採用單例模式，這是由於執行緒池要方便對池中的執行緒進行控制。 
    9. 作業系統的檔案系統，也是大的單例模式實現的具體例子，一個作業系統只能有一個檔案系統。 
   10. HttpApplication 也是單位例的典型應用。熟悉ASP.Net(IIS)的整個請求生命週期的人應該知道HttpApplication也是單例模式，所有的HttpModule都共享一個HttpApplication例項. 

2.2.  觀察者模式(Observer)

     物件間一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被自動更新。Android中的各種Listener就使用到了這一設計模式，只要使用者對手機進行操作，對應的listener就會被通知，並作出響應的處理。 
 
看不懂圖的人端著小板凳到這裡來，給你舉個栗子��：假設有三個人，小美（女，28），老王和老李。小美很漂亮，很風騷，老王和老李是兩個中年男屌絲，時刻關注著小美的一舉一動。有一天，小美說了一句：我老公今天不在家，一個人好無聊啊～～～，這句話被老王和老李聽到了，結果樂壞了，蹭蹭蹭，沒一會兒，老王就衝到小美家門口了，於是進門了………
在這裡，小美是被觀察者，老王和老李是觀察者，被觀察者發出一條資訊，然後被觀察者進行相應的處理，看程式碼：

public interface Person {
    //老王和老李通過這個介面可以接收到小美髮過來的訊息
    void getMessage(String s);
}

這個介面相當於老王和老李的電話號碼，小美髮送通知的時候就會撥打getMessage這個電話，撥打電話就是呼叫介面，看不懂沒關係，先往下看

public class LaoWang implements Person {

    private String name = "老王";

    public LaoWang() {
    }

    @Override
    public void getMessage(String s) {
        System.out.println(name + "接到了小美打過來的電話，電話內容是：" + s);
    }

}

public class LaoLi implements Person {

    private String name = "老李";

    public LaoLi() {
    }

    @Override
    public void getMessage(String s) {
        System.out.println(name + "接到了小美打過來的電話，電話內容是：->" + s);
    }

}

程式碼很簡單，我們再看看小美的程式碼：

public class XiaoMei {
    List<Person> list = new ArrayList<Person>();
     public XiaoMei(){
     }

     public void addPerson(Person person){
         list.add(person);
     }

     //遍歷list，把自己的通知傳送給所有暗戀自己的人
     public void notifyPerson() {
         for(Person person:list){
             person.getMessage("今天家裡就我一個人，你們過來吧，誰先過來誰就能得到我!");
         }
     }
}

我們寫一個測試類來看一下結果對不對

public class Test {
    public static void main(String[] args) {

        XiaoMei xiao_mei = new XiaoMei();
        LaoWang lao_wang = new LaoWang();
        LaoLi lao_li = new LaoLi();

        //老王和老李在小美那裡都註冊了一下
        xiao_mei.addPerson(lao_wang);
        xiao_mei.addPerson(lao_li);

        //小美向老王和老李傳送通知
        xiao_mei.notifyPerson();
    }
}

執行結果我截圖了 
 
完美～～～

2.3.  裝飾者模式 （Decorator Pattern）

對已有的業務邏輯進一步的封裝，使其增加額外的功能，如java中的IO流就使用了裝飾者模式，使用者在使用的時候，可以任意組裝，達到自己想要的效果。 
舉個栗子，我想吃三明治，首先我需要一根大大的香腸，我喜歡吃奶油，在香腸上面加一點奶油，再放一點蔬菜，最後再用兩片面包加一下，很豐盛的一頓午飯，營養又健康，那我們應該怎麼來寫程式碼呢？ 
首先，我們需要寫一個Food類，讓其他所有食物都來繼承這個類，看程式碼：

public class Food {

    private String food_name;

    public Food() {
    }

    public Food(String food_name) {
        this.food_name = food_name;
    }

    public String make() {
        return food_name;
    };
}

程式碼很簡單，我就不解釋了，然後我們寫幾個子類繼承它：

//麵包類
public class Bread extends Food {

    private Food basic_food;

    public Bread(Food basic_food) {
        this.basic_food = basic_food;
    }

    public String make() {
        return basic_food.make()+"+麵包";
    }
}

//奶油類
public class Cream extends Food {

    private Food basic_food;

    public Cream(Food basic_food) {
        this.basic_food = basic_food;
    }

    public String make() {
        return basic_food.make()+"+奶油";
    }
}

//蔬菜類
public class Vegetable extends Food {

    private Food basic_food;

    public Vegetable(Food basic_food) {
        this.basic_food = basic_food;
    }

    public String make() {
        return basic_food.make()+"+蔬菜";
    }

}

這幾個類都是差不多的，構造方法傳入一個Food型別的引數，然後在make方法中加入一些自己的邏輯，如果你還是看不懂為什麼這麼寫，不急，你看看我的Test類是怎麼寫的，一看你就明白了

public class Test {
    public static void main(String[] args) {
        Food food = new Bread(new Vegetable(new Cream(new Food("香腸"))));
        System.out.println(food.make());
    }
}

看到沒有，一層一層封裝，我沒從裡往外看：最裡面我new了一個香腸，在香腸的外面我包裹了一層奶油，在奶油的外面我又加了一層蔬菜，最外面我放的是麵包，是不是很形象，哈哈 ~ 這個設計模式簡直跟現實生活中一摸一樣，看懂了嗎？ 
我們看看執行結果吧 
 
一個三明治就做好了～～～

應用例項：

       1、孫悟空有 72 變，當他變成"廟宇"後，他的根本還是一隻猴子，但是他又有了廟宇的功能。

       2、不論一幅畫有沒有畫框都可以掛在牆上，但是通常都是有畫框的，並且實際上是畫框被掛在牆上。在掛在牆上之前，畫可以被蒙上玻璃，裝到框子裡；這時畫、玻璃和畫框形成了一個物體。

優點：裝飾類和被裝飾類可以獨立發展，不會相互耦合，裝飾模式是繼承的一個替代模式，裝飾模式可以動態擴充套件一個實現類的功能。

缺點：多層裝飾比較複雜。

適用環境:

（1）在不影響其他物件的情況下，以動態、透明的方式給單個物件新增職責。

（2）處理那些可以撤消的職責。

（3）當不能採用生成子類的方法進行擴充時。一種情況是，可能有大量獨立的擴充套件，為支援每一種組合將產生大量的 子類，使得子類數目呈爆炸性增長。另一種情況可能是因為類定義被隱藏，或類定義不能用於生成子類。

2.4. 介面卡模式 

介面卡模式（Adapter Pattern）是作為兩個不相容的介面之間的橋樑。這種型別的設計模式屬於結構型模式，它結合了兩個獨立介面的功能。

這種模式涉及到一個單一的類，該類負責加入獨立的或不相容的介面功能。舉個真實的例子，讀卡器是作為記憶體卡和筆記本之間的介面卡。您將記憶體卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取記憶體卡。

假設一個手機充電器需要的電壓是20V，但是正常的電壓是220V，這時候就需要一個變壓器，將220V的電壓轉換成20V的電壓，這樣，變壓器就將20V的電壓和手機聯絡起來了。

public class Test {
    public static void main(String[] args) {
        Phone phone = new Phone();
        VoltageAdapter adapter = new VoltageAdapter();
        phone.setAdapter(adapter);
        phone.charge();
    }
}

// 手機類
class Phone {

    public static final int V = 220;// 正常電壓220v，是一個常量

    private VoltageAdapter adapter;

    // 充電
    public void charge() {
        adapter.changeVoltage();
    }

    public void setAdapter(VoltageAdapter adapter) {
        this.adapter = adapter;
    }
}

// 變壓器
class VoltageAdapter {
    // 改變電壓的功能
    public void changeVoltage() {
        System.out.println("正在充電...");
        System.out.println("原始電壓：" + Phone.V + "V");
        System.out.println("經過變壓器轉換之後的電壓:" + (Phone.V - 200) + "V");
    }
}

介面卡模式優點： 1、可以讓任何兩個沒有關聯的類一起執行。 2、提高了類的複用。 3、增加了類的透明度。 4、靈活性好。

缺點： 1、過多地使用介面卡，會讓系統非常零亂，不易整體進行把握。比如，明明看到呼叫的是 A 介面，其實內部被適配成了 B 介面的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是很有必要，可以不使用介面卡，而是直接對系統進行重構。 2.由於 JAVA 至多繼承一個類，所以至多隻能適配一個適配者類，而且目標類必須是抽象類。

使用場景：有動機地修改一個正常執行的系統的介面，這時應該考慮使用介面卡模式。

注意事項：介面卡不是在詳細設計時新增的，而是解決正在服役的專案的問題。

2.5. 工廠模式 （Factory Pattern）

就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。簡單工廠模式的實質是由一個工廠類根據傳入的引數，動態決定應該建立哪一個產品類（這些產品類繼承自一個父類或介面）的例項。

實現方式:

a)     抽象產品類（也可以是介面）

b)     多個具體的產品類

c)     工廠類（包括建立a的例項的方法）

簡單工廠模式：一個抽象的介面，多個抽象介面的實現類，一個工廠類，用來例項化抽象的介面

// 抽象產品類
abstract class Car {
    public void run();

    public void stop();
}

// 具體實現類
class Benz implements Car {
    public void run() {
        System.out.println("Benz開始啟動了。。。。。");
    }

    public void stop() {
        System.out.println("Benz停車了。。。。。");
    }
}

class Ford implements Car {
    public void run() {
        System.out.println("Ford開始啟動了。。。");
    }

    public void stop() {
        System.out.println("Ford停車了。。。。");
    }
}

// 工廠類
class Factory {
    public static Car getCarInstance(String type) {
        Car c = null;
        if ("Benz".equals(type)) {
            c = new Benz();
        }
        if ("Ford".equals(type)) {
            c = new Ford();
        }
        return c;
    }
}

public class Test {

    public static void main(String[] args) {
        Car c = Factory.getCarInstance("Benz");
        if (c != null) {
            c.run();
            c.stop();
        } else {
            System.out.println("造不了這種汽車。。。");
        }

    }

}

工廠方法模式：有四個角色，抽象工廠模式，具體工廠模式，抽象產品模式，具體產品模式。不再是由一個工廠類去例項化具體的產品，而是由抽象工廠的子類去例項化產品

// 抽象產品角色
public interface Moveable {
    void run();
}

// 具體產品角色
public class Plane implements Moveable {
    @Override
    public void run() {
        System.out.println("plane....");
    }
}

public class Broom implements Moveable {
    @Override
    public void run() {
        System.out.println("broom.....");
    }
}

// 抽象工廠
public abstract class VehicleFactory {
    abstract Moveable create();
}

// 具體工廠
public class PlaneFactory extends VehicleFactory {
    public Moveable create() {
        return new Plane();
    }
}

public class BroomFactory extends VehicleFactory {
    public Moveable create() {
        return new Broom();
    }
}

// 測試類
public class Test {
    public static void main(String[] args) {
        VehicleFactory factory = new BroomFactory();
        Moveable m = factory.create();
        m.run();
    }
}

 

優點：

工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據外界給定的資訊,決定究竟應該建立哪個具體類的物件.通過使用工廠類,外界可以從直接建立具體產品物件的尷尬局面擺脫出來,僅僅需要負責“消費”物件就可以了。而不必管這些物件究竟如何建立及如何組織的．明確了各自的職責和權利，有利於整個軟體體系結構的優化。

缺點：

由於工廠類集中了所有例項的建立邏輯，違反了高內聚責任分配原則，將全部建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，如果需要新增新的類，則就需要改變工廠類了。當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件建立不同例項的需求．這種對條件的判斷和對具體產品型別的判斷交錯在一起，很難避免模組功能的蔓延，對系統的維護和擴充套件非常不利；

2.6. 抽象工廠模式 （Abstract Factory Pattern）

與工廠方法模式不同的是，工廠方法模式中的工廠只生產單一的產品，而抽象工廠模式中的工廠生產多個產品

/抽象工廠類
public abstract class AbstractFactory {
    public abstract Vehicle createVehicle();
    public abstract Weapon createWeapon();
    public abstract Food createFood();
}
//具體工廠類，其中Food,Vehicle，Weapon是抽象類，
public class DefaultFactory extends AbstractFactory{
    @Override
    public Food createFood() {
        return new Apple();
    }
    @Override
    public Vehicle createVehicle() {
        return new Car();
    }
    @Override
    public Weapon createWeapon() {
        return new AK47();
    }
}
//測試類
public class Test {
    public static void main(String[] args) {
        AbstractFactory f = new DefaultFactory();
        Vehicle v = f.createVehicle();
        v.run();
        Weapon w = f.createWeapon();
        w.shoot();
        Food a = f.createFood();
        a.printName();
    }
}

 

持續更新中。。。。。。

 

 

參考連結：

幾種常用的設計模式介紹

面試必備：常用的設計模式總結

十種常用的設計模式(大部分自己總結，部分摘抄)