2. 程式人生 > >淺談開發中常用的設計模式

淺談開發中常用的設計模式

阿新 • • 發佈：2019-01-24

設計模式在開發中佔很重要的地位。在大型專案中使用好設計模式往往會取得事半功倍的效果。本篇部落格就介紹下幾種在開發中常用到的設計模式。

設計原則

先看下一些約定俗成的設計原則，其實要遵守以下所有原則很難，但開發過程中還是要有這樣的意識。

  • 找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的程式碼混在一起。（封裝變化）
  • 針對介面程式設計，而不是針對實現程式設計。
  • 多用組合，少用繼承：用組合建立的系統具有很大的彈性，不僅可以將演算法封裝成類，也可以在執行時動態地改變行為。總結一句話就是，有一個比是一個更好。
  • 為互動物件之間的鬆耦合設計而努力。
  • 對擴充套件開放，對修改關閉。（裝飾者是很好的體現）
  • 要依賴抽象，不要依賴具體類。這就是依賴倒置原則。它更強調的是抽象，不能讓高層元件依賴低層元件。
  • 最少知識原則：只和你的密友談話。就是說當你在設計一個系統，不管任何物件，你都要注意它所互動的類有哪些。不要讓太多的類藕合在一起。
  • 單一模式：一個類應該只有一個引起變化的原因。

模式介紹

策略模式

策略模式定義是：定義演算法族，分別封裝起來，讓它們之間可以互相替換，演算法的變化獨立於使用演算法的客戶。
我們來模擬一種情形來理解這句話。有一群鴨子，有各種顏色的鴨，他們有的會飛，有的不會飛，飛的姿態也更不相同。此時如果在每隻鴨子裡分別定義飛的姿態，那有成千上萬中鴨子的時候就會累死。這時我們考慮使用設計模式來實現下它。
設計原則中第一條：找出應用中可能需要變化之處，把它們獨立出來。當然這裡我們獨立的就是會變化的飛行為。
設計模式第二條：針對介面程式設計，而不是針對實現程式設計。所以到這裡我們寫出如下飛的程式碼：

public interface FlyBehavior {
    public void fly();
}

定義了介面類，再定義實現類，會簡單，只定義會飛和不會飛行為：

public class NoFly implements FlyBehavior {

    @Override
    public void fly() {
        // TODO Auto-generated method stub
        System.out.println("this duck can not fly");
    }


}

public class CanFly
 
 implements FlyBehavior{

    @Override
    public void fly() {
        // TODO Auto-generated method stub
        System.out.println("this duck can fly");
    }

}

以上就是針對介面程式設計，那它有什麼好處呢，繼續往下看。
設計原則第三條：多用組合，少用繼承。那我們也來運用下。定義鴨子的抽象類：

public abstract class Duck {
    FlyBehavior flyBehavior;

    public abstract void disply();

    public  void performFly(){
        flyBehavior.fly();
    }

    public FlyBehavior getFlyBehavior() {
        return flyBehavior;
    }
    public void setFlyBehavior(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }

}

其中它有一個FlyBehavior物件，組合了飛的行為，典型的“有一個“而不是”有一個“。
好了，接下來就是實體鴨子， 只要繼承超類就可以了。

public class RedDuck extends Duck{

    public RedDuck() {
        // TODO Auto-generated constructor stub
        flyBehavior = new NoFly();//預設不會飛

    }
    @Override
    public void disply() {
        // TODO Auto-generated method stub
        System.out.println("the color is red");
    }

}

紅鴨不會飛，再來一隻黑鴨會飛：

public class BlackDuck extends Duck{

    public BlackDuck() {
        // TODO Auto-generated constructor stub
        flyBehavior = new CanFly();//預設不會飛

    }
    @Override
    public void disply() {
        // TODO Auto-generated method stub
        System.out.println("the color is black");
    }
}

最後我們來呼叫一下：

public class Main {
    public static void main(String[] args){
        Duck duck = new RedDuck();
        duck.performFly();
        duck.disply();
        duck.setFlyBehavior(new CanFly());
        duck.performFly();
        System.out.println("-----------------");
        Duck duck2 = new BlackDuck();
        duck2.performFly();
        duck2.disply();
        duck2.setFlyBehavior(new NoFly());
        duck2.performFly();
    }
}

這就是大名鼎鼎的策略模式。好處己經非常明顯了，要什麼飛行行為只要在執行時進行替換就可以了。這種模式的好處：實現不會被綁死在子類中，使用介面，可以執行時替換。看上它的UML圖：
這裡寫圖片描述

觀察者模式

定義了物件之間的一對多依賴，這樣一來，當一個物件改變時，它的所有依賴者都會收到通知並自動更新。
模擬場景的話很簡單，就是比如圖書館，你在圖書館借書，相當於你就是圖書館的一個觀察者，當圖書館有新聞釋出時你就會收到通知。
先看一下它的UML圖：
這裡寫圖片描述
從觀察人員入手：

public interface Observer {

    public void update(String name);
    public void disConnect();
}

只需要兩個方法，有訊息更新後會通知你（update）。如果你覺得煩也可以取消觀察。新建實現類小明：

public class XiaoMingObserver implements Observer{
    String bookName;
    private Subject subject;
    public XiaoMingObserver(Subject subject) {
        // TODO Auto-generated constructor stub
        this.subject = subject;
        subject.registerObserver(this);
    }
    @Override
    public void update(String name) {
        // TODO Auto-generated method stub

        System.out.println ("i am xiaoMing,the new book is "+name);
    }
    @Override
    public void disConnect() {
        // TODO Auto-generated method stub
        this.subject.removeObserver(this);
    }
}

小明擁有圖書證（有一個Subject 物件），subject註冊了它，它就成了一個觀察者，看下subject：

public interface Subject {
    public void registerObserver(Observer o);
    public void removeObserver(Observer o);
    public void notifyObservers();
}

實現三個功能，註冊觀察者，刪除觀察者，通知變化。可見它要擁有觀察者物件。看下具體的實現。

public class BookSubject implements Subject {
    private String bookName;
    ArrayList<Observer> aList; 
    public BookSubject() {
        // TODO Auto-generated constructor stub
        aList = new ArrayList<Observer>();
    }
    @Override
    public void registerObserver(Observer o) {
        // TODO Auto-generated method stub
            aList.add(o);

    }

    @Override
    public void removeObserver(Observer o) {
        // TODO Auto-generated method stub
        if(aList.contains(o)){
            aList.remove(o);
        }
    }

    @Override
    public void notifyObservers() {
        for(Observer observer :aList){
            if(observer instanceof XiaoGaoObserver){
                bookName = "java程式設計思想";
            }else{
                bookName = "c++程式設計思想";
            }

            observer.update(bookName);

    }
    }
}

registerObserver新增觀察者到List中。釋出通知也就是呼叫觀察者的Notify方法。觀察者在android原始碼中就很我地方體現，如Adapter中就是觀察資料變化就更改介面。以後有時間寫下Adapter的原始碼分析。

工廠模式

工廠模式有三種，個人感覺工廠模式還是比較複雜的。一步步講吧，最後會把原始碼附上。

1.簡單工廠模式

簡單工廠模式最好理解，平時用得也很多。簡單工廠模式主要是在初始化物件進行解耦合，工廠模式封裝了建立物件的細節。一般是靜態方法。但使用靜態方法有一個缺點，就是無法通過繼承來改變物件建立過程。
我們來模擬一個場景，假設我們在賣腸粉（最愛腸粉了。。。）。我們要做很多口味，這時不能做一種口味就new一個腸粉，因為做腸粉只有前面加料時步驟不一樣，後面的切跟蒸都是一樣的。先看上UML圖：
這裡寫圖片描述
所以我們用簡單工廠模式寫出以下程式碼：

public class SimpleChangfenStore {
    SimpleFactory mFactory = null;
    public SimpleChangfenStore(SimpleFactory factory){
        this.mFactory = factory;
    }
    public void orderChangfen(String tag){
        Changfen mChangfen = null;
        mChangfen = mFactory.createChangfen(tag);
        mChangfen.prepare();
        mChangfen.bake();
        mChangfen.cut();
        System.out.println("------finish one-------");
    }
}

createChangfen的作用就是用於抽取出來專門建立腸粉物件，這樣做的好處是可以防止你每次新增一種口味的腸粉都要修改這個類。看下它的程式碼：

public class SimpleFactory {
    public Changfen createChangfen(String tag){ 
        Changfen changfen = null;
        if(tag.equals("vegetable")){
            changfen = new VegetableChangfen();
    }else if(tag.equals("meat")){
        changfen = new MeatChangfen();
    }
    return changfen;
    }
}

根據tag建立不同的腸粉。最後來看下如何使用：

public class SimpleMain {
    public static void main(String[] args){
        SimpleFactory factory = new SimpleFactory();
        SimpleChangfenStore store = new SimpleChangfenStore(factory);
        store.orderChangfen("meat");
        store.orderChangfen("vegetable");
    }
}

很簡單，只要知道factory專門用來建立物件的就可以了。看下輸出結果：
這裡寫圖片描述
接下來看下工廠模式。

工廠模式

工廠模式：把建立changfen分為子類中，定義一個建立物件的介面，但由子類決定要例項化的類是哪一個，工廠方法讓類把例項化推遲到子類。
其實也很好理解，先看下UML圖：
這裡寫圖片描述
回到我們的腸粉店，現在我們的生意很好，要開分店啦，很開心。在深圳和汕頭更來一家店。那深圳和汕頭建立的店物件肯定是不同的嘛。所以類的例項化在到子類中，讓子類自己來建立。為此，我們的店要把建立物件的方法定義成抽象的。

public abstract class ChangfenStore {
    public abstract Changfen createChangfen(String tag);
    public void orderChangfen(String tag){
        Changfen mChangfen = null;
        mChangfen = createChangfen(tag);
        mChangfen.prepare();
        mChangfen.bake();
        mChangfen.cut();
        System.out.println("------finish one-------");
    }
}

createChangfen定義成抽象的了，要由子類來實現，看下深圳的子類：

public class SZStore extends ChangfenStore{

    @Override
    public Changfen createChangfen(String tag) {
        // TODO Auto-generated method stub
        Changfen changfen = null;
        if(tag.equals("vegetable")){
            changfen = new SZVegetableChangfen();
    }else if(tag.equals("meat")){
        changfen = new SZMeatChangfen();

    }
    return changfen;
    }

}

看吧，深圳用的是深圳的肉和菜，小看一眼：

public class SZVegetableChangfen extends Changfen{

    @Override
    public void prepare() {
        // TODO Auto-generated method stub
        System.out.println("i am in Shenzhen,i like the cabbage,so i add the cabbage");
    }

}

這樣就實現了工廠模式。看下如何使用：

public class Main {
    public static void main(String[] args){
        ChangfenStore SZstore = new SZStore();
        SZstore.orderChangfen("meat");
        SZstore.orderChangfen("vegetable");

        ChangfenStore STstore = new STStore();
        STstore.orderChangfen("meat");
        STstore.orderChangfen("vegetable");
    }
}

輸出如下：
這裡寫圖片描述
好啦 ，接下來講講抽象工廠方法啦。

抽象工廠方法

抽象工廠模式：提供一個介面，用於建立或依賴物件的家族，而不需要明確指定具體類。它提供了一個原料的生產工廠，原料的生產對客戶不可見。
不太好理解，其實就是建立一些依賴物件的原料。繼續看我們的腸粉。我們深圳店和汕頭店加的原料肯定是不同的，即使是用魚，那魚的種類也不一定相同。用一句話說就是深圳店和汕頭店要有自己的原料工廠。
原料嘛，就要有原料工廠，先看下原料工廠：

public abstract class AbstractChangfenFactory {
    public abstract Flour createFlour();
    public abstract Sauce createSauce();
    public abstract Seasoning createseasoning();

}

它是一個抽象類。腸粉要加醬加料等。具體加哪些醬哪些料，看具體實現類：

public class SZChangfenFactory extends AbstractChangfenFactory{
    @Override
    public Flour createFlour() {
        // TODO Auto-generated method stub
        return new SZFlour();
    }

    @Override
    public Sauce createSauce() {
        // TODO Auto-generated method stub
        return  new SZSauce();
    }

    @Override
    public Seasoning createseasoning() {
        // TODO Auto-generated method stub
        return new SZSessioning();
    }
}

看吧，是深圳特有的SZSauce，SZFlour等。這些都是物件，本例子只是簡單的列印一句話，這裡就不貼出來了，具體就不貼出來了。要記得汕頭也有自己的原料STSauce等。
原料都買好了，開始做腸粉吧：

public abstract class AbstractChangfen{
    protected Sauce mSauce = null;
    protected Flour mFlour = null;
    protected Seasoning mSeasioning = null;

    public abstract void prepare();
    public void bake(){
        System.out.println("after prepare,the Changfen should be bake");
    }
    public void cut(){
        System.out.println("after bake,the Changfen should be cut");
    }
}

看下深圳是怎麼做的，來到深圳分店視察：

public class STStore extends ChangfenStore{

    @Override
    public AbstractChangfen createChangfen(String tag) {
        AbstractChangfen changfen = null;
        AbstractChangfenFactory factory;
        factory = new STChangfenFactory();
        if(tag.equals("vegetable")){
            changfen = new STAbstractVegetableChangfen(factory);
    }else if(tag.equals("meat")){
        changfen = new STAbstractMeatChangfen(factory);

    }
    return changfen;
    }

}

深圳人嘛，要記得選擇深圳的原料工廠哦。選其中的做肉腸粉的程式碼來看一看：

public class STAbstractMeatChangfen extends AbstractChangfen{

    private AbstractChangfenFactory mFactory = null;
    public  STAbstractMeatChangfen(AbstractChangfenFactory factory) {
        // TODO Auto-generated constructor stub
        this.mFactory = factory;
    }
    @Override
    public void prepare() {
        // TODO Auto-generated method stub
        this.mSauce = this.mFactory.createSauce();
        this.mFlour = this.mFactory.createFlour();
        System.out.println("i am in ShanTou factory,i like meat,the sause is "+this.mSauce.print()+",the flour is "+this.mFlour.print());

    }

}

到此就一目瞭然了，深圳用深圳的原料，汕頭用汕頭的原料。輸出結果如下：
這裡寫圖片描述
到此工廠模式就講完了。看下UML圖。畫得比較複雜，細心看，能看懂的。
這裡寫圖片描述
篇幅關係，還有幾個常用設計模式下篇再總結。先到這吧。

相關推薦

淺談開發中常用的設計模式

設計模式在開發中佔很重要的地位。在大型專案中使用好設計模式往往會取得事半功倍的效果。本篇部落格就介紹下幾種在開發中常用到的設計模式。 設計原則 先看下一些約定俗成的設計原則，其實要遵守以下所有原則很難，但開發過程中還是要有這樣的意識。 找出應用中可能

淺談springMVC中的設計模式(5)——組合模式

相信大家在使用springMVC的時候，都或多或少需要對它進行配置，不管使用xml的方式還是Java註解的方式。今天我們就從springMVC的配置上，談一談其中一個很重要的設計模式：組合模式。 定義 慣例我們先來看一看組合模式的定義：組合模式，將物件組合成

淺談springMVC中的設計模式(1)——責任鏈模式

最近終於閒了下來，準備自己記錄些東西。網上關於springMVC的資料很多，但關於設計模式的還有限，我就想把springMVC原始碼中的設計模式抽出來做成一個系列，簡單的談一下其中的實現原理，作為一種學習分享，以後有更深的感悟也會更新。 先從一張圖對整個spr

淺談遊戲中BOSS設計的思路

移動 進程 經典 它的 操作技巧 時有 設計時 註意 有著 對於大多數遊戲來說，BOSS在其設計上都有著不可替代的作用，也是玩家印象最為深刻的一部分。近期自己也有在做BOSS的設計工作，有一些心得想要分享一下： 1.明確BOSS的設計目的 在設計之初，我們一定要想明白，設計

淺談UML中常用的幾種圖——用例圖

多個 spa log 分享 擴展 有關 包圖 可見 發的 1.UML簡介 　　統一建模語言（Unified Modeling Language，UML）又稱標準建模語言，是始於1997年的一個OMG標準，它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供

java中常用設計模式

一.java的設計模式大體上分為三大類： 建立型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。 結構型模式（7種）：介面卡模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。 行為型模式（11種）：策略模式、模板方法模

Android中常用設計模式

介紹 Java 中一般認為有 23 種設計模式，我們不需要所有的都會，但是其中常用的幾種設計模式應該去掌握。下面列出了所有的設計模式。需要掌握的設計模式我單獨列出來了，當然能掌握的越多越好。 總體來說設計模式分為三大類： 建立型模式，共五種：工廠方法模式、

淺談android的MVP設計模式之記憶體洩露問題

我上次寫了淺談mvp，經過一段時間的思考，發現我忽略了一個問題 記憶體洩露問題。 因為Presenter中持有View介面物件，這個介面物件實際為MainActivity.this，Modle中也同時擁有Presenter物件例項，當MainActivi

以C/C++語法淺談二十三種設計模式（一）——工廠模式（Factory Method）

0.寫在前面 在軟體開發過程中，為了提高開發效率、增強軟體執行的穩定性，降低後期專案維護的成本，我們志在追求更加高效、簡單的設計思路來引領我們的專案產品，在經過不斷的探索與總結的過程中，我們最常用的設計模式有23中，總體分為三大類，即建立型模式、結構型模式和行為型模式，具體如下：

淺談Spring Mvc的設計模式

Spring Mvc這個框架給我的第一感覺是大大的優化了web層，特別是配合註解的形式，對於比較中小型的網站，我個人覺得還是比較適合的。 Spring Mvc的底層實現核心是基於Aop的，DispatcherServlet作為攔截器的核心，負責接受所有的攔截請求，這也是Ao

程式開發中的設計模式彙總整理

在我們日常開發過程中設計模式伴隨著專案的各個模組，合理地使用設計模式可以讓我們寫出更高效、簡潔的程式碼。 淺談設計模式的優缺點 什麼是設計模式 設計模式是為了解決特定場景下的問題而定製的解決方案。 優點 合理的使用設計模式可以減低程式碼耦

淺談iOS中常用加密演算法的使用

 以前如果我們忘記了登入密碼，通常可以通過“找回密碼”這樣的方式拿回密碼，那說明你的隱私資料在他們的資料庫中是明文儲存的，現在請切記：如果哪個平臺還有這樣的方式請立刻馬上登出你的賬號，並避免在任何其他平臺使用這個平臺使用過的密碼。請堅信：在網路世界中，只要是明文存在或可逆的東西，都是不安全的。沒有哪家公司會告

橋接模式+遊戲開發中的設計模式——橋接者模式

設計模式總結之Bridge Pattern（橋接模式） https://blog.csdn.net/cooldragon/article/details/52173915 何為橋接模式 橋接模式（Bridge）:將抽象部分和他的實現部分分離，使他們都可以獨立工作 例如：角色裝備

中介者模式+遊戲開發中的設計模式——中介者模式

siki學院學習筆記——中介者模式 設計模式之中介者模式（Mediator） http://www.cnblogs.com/BeyondAnyTime/archive/2012/08/30/2663922.html 何為中介者模式 中介者模式(Mediator):用一箇中介物件來封裝

單例模式+遊戲開發中的設計模式——單例模式

01、設計模式：這是最全面 & 詳細的 單例模式（Singleton）分析指南 https://blog.csdn.net/carson_ho/article/details/52223097 02、單例模式的優缺點 https://blog.csdn.net/iblade/ar

外觀模式+遊戲開發中的設計模式——外觀模式

何為外觀模式 外觀模式（Facade）:為子系統中的一組介面提供一個一致的介面，此模式定義了一個高層介面，這個介面使子系統更加容易使用 依賴倒轉原則+迪米特法則思想    程式碼實現 using System; using System.Collecti

遊戲開發中的設計模式——狀態模式

Siki學院——遊戲開發中的設計模式 狀態模式—— 菜鳥篇個人學習筆記 案例開發——應用於場景轉換 由StartState場景，自動跳轉到MainMenuState場景，點選按鈕後，跳轉到BattleState場景  GameLoop 採用了指令碼和遊戲物體

淺談Android中的MVVM模式

大家好啊，我是kele。眾所周知，Android的設計模式主要有三個：MVC,MVP,MVVM。今天主要來談一下MVVM模式，簡單說明它的好處以及它和MVP在實現方面的區別。 DataBinding android { ....

淺談java 23種設計模式之模板方法模式（Template ）

模板方法模式：模板方法模式是類的行為模式的一種，符合開閉原則（對擴充套件開放，對修改關閉）。父類提取子類公共方法，並提供若干抽象方法供子類實現，以減少子類中的重複程式碼，並提高可複用性。示例：1.建立一個父類bird，每天只有吃和睡才能生活，但是必須要先進行吃，然後再進行睡：

遊戲開發中的設計模式——1.狀態模式

這篇博文我記錄了狀態模式在遊戲開發中的簡單應用，用於與切換各個遊戲場景。但是在實際的遊戲開發中，本人並不建議使用這種方式切換遊戲場景，因為Unity本來就是基於元件的遊戲引擎。但是，知識學多了有害無益，為了學習而學習嘛。 先上總圖： 上圖中分為兩個模組，