2. 程式人生 > >運用設計模式告別專案中大量臃腫的if else

運用設計模式告別專案中大量臃腫的if else

阿新 • • 發佈：2020-07-03

前言

以前寫過的一個老專案中，有這樣一個業務場景，比喻：一個外賣系統需要接入多家餐館，在外賣系統中返回每個餐館的選單列表 ，每個餐館的菜單價格都需要不同的演算法計算。

程式碼中使用了大量的if else巢狀連線，一個類中數千行程式碼(眼睛快看瞎...)，而且隨著業務的擴充套件，接入的餐館會越來越多，每接入一個餐館都要增加一個 if else，滿螢幕密密麻麻的邏輯程式碼，毫無可讀性。然後前段時間進行了程式碼重構，使用了策略模式+工廠模式+反射代替了這整片的臃腫程式碼，瞬間神清氣爽。

 

模擬原業務程式碼

原始碼的簡單模擬實現，根據傳入的不同餐館編碼獲取對應的餐館類集合，每個餐館菜單價格的演算法都不同。每當需要新接入一家餐館時，都需要在此增加一個if else，中間加入一大長串的處理邏輯，當餐館越來越多的時候，程式碼就變得越來越沉重，維護成本高。

public List server(String hotelCode) {
    if ("HotelA".equals(hotelCode)) {
        //獲取資料
        List<HotelA> hotelList = new ArrayList<HotelA>() {
            {
                add(new HotelA("爆炒腰子", 100d, 0.8, null));
                add(new HotelA("紅燒腰子", 200d, 0.8, null));
                add(new HotelA("腰子刺身", 300d, 0.8, null));
            }
        };
        //邏輯計算 最終價格 = 原價 * 折扣
        hotelList.parallelStream().forEach(v -> v.setFinalPrice(v.getPrice() * v.getDiscount()));
        return hotelList;

    } else if ("HotelB".equals(hotelCode)) {
        //獲取資料
        List<HotelB> hotelList = new ArrayList<HotelB>() {
            {
                add(new HotelB("蘭州拉麵", 100d, 10d, null));
                add(new HotelB("落魄後端線上炒粉", 200d, 20d, null));
            }
        };
        //邏輯計算 最終價格 = 原價 - 優惠
        hotelList.parallelStream().forEach(v -> v.setFinalPrice(v.getPrice() - v.getPreferential()));
        return hotelList;

    } else if ("HotelC".equals(hotelCode)) {
        //獲取資料
        List<HotelC> hotelList = new ArrayList<HotelC>() {
            {
                add(new HotelC("祕製奧利給", 1000d, 0.6, 20d, null));
                add(new HotelC("老八辣醬", 2000d, 0.6, 10d, null));
            }
        };
        //邏輯計算 最終價格 = 原價 * 折扣 - 服務費
        hotelList.parallelStream().forEach(v -> v.setFinalPrice(v.getPrice() * v.getDiscount() - v.getTip()));
        return hotelList;
    }
    return new ArrayList();
}

 

@Data
@NoArgsConstructor
@AllArgsConstructor
public class HotelA {

    //菜品名
    private String menu;

    //原價
    private Double price;

    //折扣
    private Double discount;

    //最終價格 = 原價 * 折扣
    private Double finalPrice;
}
@Data
@NoArgsConstructor
@AllArgsConstructor
public class HotelB {

    //菜品名
    private String menu;

    //原價
    private Double price;

    //優惠
    private Double preferential;

    //最終價格 = 原價 - 優惠
    private Double finalPrice;
}
@Data
@NoArgsConstructor
@AllArgsConstructor
public class HotelC {

    //菜品名
    private String menu;

    //原價
    private Double price;

    //折扣
    private Double discount;

    //服務費
    private Double tip;

    //最終價格 = 原價 * 折扣 - 服務費
    private Double finalPrice;
}

 

策略模式+工廠模式+反射

由上述程式碼首先抽離出一個介面，if else中的業務邏輯最終都是返回一個列表

/**
 * 餐館服務介面
 */
public interface HotelService {

    /**
     * 獲取餐館選單列表
     * @return
     */
    List getMenuList();
}

 

 

把每個分支的業務邏輯封裝成實現類，實現HotelService介面

public class HotelAServiceImpl implements HotelService {

    /**
     * 邏輯計算 返回集合
     * @return
     */
    @Override
    public List getMenuList() {
        return initList().parallelStream()
                .peek(v -> v.setFinalPrice(v.getPrice() * v.getDiscount()))
                .collect(Collectors.toList());
    }

    /**
     * 獲取資料
     * @return
     */
    public List<HotelA> initList() {
        return new ArrayList<HotelA>() {
            {
                add(new HotelA("爆炒腰子", 100d, 0.8, null));
                add(new HotelA("紅燒腰子", 200d, 0.8, null));
                add(new HotelA("腰子刺身", 300d, 0.8, null));
            }
        };
    }
}
public class HotelBServiceImpl implements HotelService {

    /**
     * 邏輯計算 返回集合
     * @return
     */
    @Override
    public List getMenuList() {
        return initList().parallelStream()
                .peek(v -> v.setFinalPrice(v.getPrice() - v.getPreferential()))
                .collect(Collectors.toList());
    }

    /**
     * 獲取資料
     * @return
     */
    public List<HotelB> initList() {
        return new ArrayList<HotelB>() {
            {
                add(new HotelB("蘭州拉麵", 100d, 10d, null));
                add(new HotelB("落魄後端線上炒粉", 200d, 20d, null));
            }
        };
    }
}
public class HotelCServiceImpl implements HotelService {

    /**
     * 邏輯計算 返回集合
     * @return
     */
    @Override
    public List getMenuList() {
        return initList().parallelStream()
                .peek(v -> v.setFinalPrice(v.getPrice() * v.getDiscount() - v.getTip()))
                .collect(Collectors.toList());
    }

    /**
     * 獲取資料
     * @return
     */
    public List<HotelC> initList() {
        return new ArrayList<HotelC>() {
            {
                add(new HotelC("祕製奧利給", 1000d, 0.6, 20d, null));
                add(new HotelC("老八辣醬", 2000d, 0.6, 10d, null));
            }
        };
    }
}

 

 

這樣就是一個簡單的策略模式了，但是現在要呼叫不同的實現類中的getMenuList方法，好像還是離不開if else，那麼現在就需要用工廠模式把所有實現類包裝起來。

先定義一個列舉類，裡面是各餐館的code

public enum HotelEnum {

    HOTEL_A("HotelA"),
    HOTEL_B("HotelB"),
    HOTEL_C("HotelC"),;

    private String hotelCode;

    /**
     * 返回所有餐館編碼的集合
     * @return
     */
    public static List<String> getList() {
        return Arrays.asList(HotelEnum.values())
                .stream()
                .map(HotelEnum::getHotelCode)
                .collect(Collectors.toList());
    }

    HotelEnum(String hotelCode) {
        this.hotelCode = hotelCode;
    }

    public String getHotelCode() {
        return hotelCode;
    }

}

 

 

接下來定義一個服務工廠，在靜態塊中利用反射機制把所有服務實現類動態載入到HOTEL_SERVER_MAP中，然後提供一個對外的獲取對應服務的方法

這裡有幾個需要注意的地方：

1.由於包名是寫死的，那麼所有實現HotelService的實現類都需要放在固定的包下

2.類名的格式也是固定的，即列舉類中的hotelCode + "ServiceImpl"

/**
 * 服務工廠類
 */
public class HotelServerFactory {
    /**
     * 類路徑目錄
     */
    private static final String CLASS_PATH = "com.tactics.service.impl.";

    /**
     * 服務實現字尾
     */
    private static final String GAME_SERVICE_SUFFIX = "ServiceImpl";


    private static final Map<String, HotelService> HOTEL_SERVER_MAP = new ConcurrentHashMap<>();

    /**
     * 初始化實現類到COMPANY_SERVER_MAP中
     */
    static {
        HotelEnum.getList().forEach(v -> {
            String className = CLASS_PATH + v + GAME_SERVICE_SUFFIX;
            try {
                HOTEL_SERVER_MAP.put(v, (HotelService) Class.forName(className).newInstance());
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        });
    }

    /**
     * 獲取餐館服務實現
     *
     * @param hotelCode
     * @return
     */
    public static HotelService getHotelServerImpl(String hotelCode) {
        return HOTEL_SERVER_MAP.get(hotelCode);
    }
}

 

這裡有一個問題，如果你的服務實現類是交給Spring容器管理的，裡面有注入Mapper等等，使用反射的方式new出來的話，其中的屬性是沒有值的。

Spring容器就相當於是一個工廠了，可以直接從Spring上下文中獲取(怎麼獲取Spring上下文物件這裡就不細說了,有需要可以自行百度)。

/**
 * 服務工廠類
 */
public class HotelServerFactory {
    /**
     * 類路徑目錄
     */
    private static final String CLASS_PATH = "com.tactics.service.impl.";

    /**
     * 服務實現字尾
     */
    private static final String GAME_SERVICE_SUFFIX = "ServiceImpl";

    /**
     * 獲取餐館服務實現
     *
     * @param hotelCode
     * @return
     */
    public static HotelService getHotelServerImpl(String hotelCode) {
        Class clazz = Class.forName(CLASS_PATH + hotelCode + GAME_SERVICE_SUFFIX);
        String className = hotelCode + GAME_SERVICE_SUFFIX;
        return (HotelService) ApplicationConfig.getBean(className, clazz);
    }
}

 

 

最終的呼叫

public List server(String hotelCode) {
    //獲取對應的服務
    HotelService hotelService = HotelServerFactory.getCompanyServerImpl(hotelCode);
    //獲取經過邏輯計算後返回的集合列表
    return hotelService.getMenuList();
}

 

 

怎麼樣，是不是覺得可讀性，複用性和擴充套件性都大大提高了，業務擴充套件需要新加一個餐館的時候，只需要在列舉類中加一個hotelCode，然後定義一個實現類實現HotelService介面就好了，這個Demo也讓我們知道了策略模式和工廠模式在實際專案中的應用場景。

相關推薦

運用設計模式告別專案中大量臃腫的if else

前言 以前寫過的一個老專案中，有這樣一個業務場景，比喻：一個外賣系統需要接入多家餐館，在外賣系統中返回每個餐館的選單列表 ，每個餐館的菜單價格都需要不同的演算法計算。 程式碼中使用了大量的if else巢狀連線，一個類中數千行程式碼(眼睛快看瞎...)，而且隨著業務的擴充套件，接入的餐館會越來越多，每接入一個

幾種常見設計模式在專案中的應用<Singleton、Factory、Strategy>

一、前言 　　前幾天閱讀一框架文件，裡面有一段這樣的描述 “從物件工廠中………” ，促使寫下本文。儘管一些模式簡單和簡單，但是常用、有用。 　　結合最近一個專案場景回顧一下里面應用到的一些模式<Singleton、Factory、Strategy>。 　　示例程式碼：https://github.

如何優化程式碼中大量的if/else,switch/case?

前言 隨著專案的迭代，程式碼中存在的分支判斷可能會越來越多，當裡面涉及到的邏輯比較複雜或者分支數量實在是多的難以維護的時候，我們就要考慮下，有辦法能讓這些程式碼變得更優雅嗎？ 正文 使用列舉 這裡我們簡單的定義一個表示狀態的列舉。   public enum Status {

設計模式在專案架構中的最佳實踐 -- 生成器模式介面卡模式

設計模式在專案架構中的最佳實踐 – 生成器模式/介面卡模式 ​ 一年多來,做了幾個專案,雖然沒有什麼技術和業務難度,但是也不能白白浪費了自己一年的光景,除了技術也業務外,總有一些知識值得我們去總結和學習; ​ 這麼些年埋頭於苦幹,很少抽出時間來整理提高自己的綜合

設計模式在JDK中的運用

今天覆習了一下設計模式，也從原始碼中去尋找了一下設計模式在JDK中的運用。 介面卡模式： 核心思想就是將一個介面適配（偽裝成）到另一個介面。在Java I/O中運用到了很多介面卡模式，例如將字串資料轉變成位元組資料儲存到檔案中或將位元組資料轉變成流資料等，下面用InputStreamRead

Java 策略模式在專案中的實際運用

       通常來說，策略模式是指對一系列的演算法定義，並將每一個演算法封裝起來，而且使它們還可以相互替換。策略模式讓演算法獨立於使用它的客戶而獨立變化。        策略模式的優點有：策略模式提供了管理相關的演算法族的辦法、策略模式提供了可以替換繼承關係的辦法、使用策略

Java建造者模式在專案中的實際運用

建造者模式 建造者模式（Builder Pattern)是物件建立軟體設計模式，其目的是找到伸縮構造器反模式的解決方案。先簡單說一下伸縮構造器反模式是什麼：假如我們有如下建構函式： public Hero(Profession profession, Strin

設計模式在JAVA中的具體運用

前言     最近一直在看《Design Patterns: Elements of Reusable Object-Oriented Software》這本書，不知道看過這本書的人是不是有摸不到頭緒，無處下手的感覺， OK，和我一樣/hand. 書裡面講述的23種模式經

MVC設計模式在網站中的應用

設計 分享 階段 可用性 狀態 代碼 img 多個 如果 MVC設計模式在網站中的應用 以淘寶的購物車為例 一、結合六個基本質量屬性 可修改性 采用MVC設計模式的時候，可以將視圖、模型、控制器分析，將用戶動作、數據表示、應用數據分離開來，如果用戶需要以不同的視圖來展示，只

設計模式在遊戲中的應用--原型模式（六）

markdown 什麽 java 原型模型 char mod 結構圖 void -s Prototype原型模式是一種創建型設計模式，Prototype模式同意一個對象再創建另外一個可定制的對象，根本無需知道不論什麽怎樣創建的細節,工作原理是:通過將一個

設計模式在遊戲中的應用--模板方法（七）

一次 cli ces 情況下 sheet skill 對象 cal 模式 模板方法這個名字看著非常陌生，事實上在遊戲中大量地使用了模板方法。由於遊戲中存在玩家、NPC

Decorator設計模式的實現中 裝飾設計模式學習筆記

Decorator設計模式的實現中 裝飾裝飾設計模式 a)當某個類的某個方法不適應當前業務的需要思路：》擴展父類的可供擴展的方法，可以使有，但不優》裝飾設計模式(推薦) 開發步驟： 1)寫一個普通類或寫一個普通類擴展[extends]一個父類 2)寫一個需要被包裝的實例變量 3)通過構造方式為被包裝的實例變量

23種設計模式在Android中的應用

ets ros 而不是 auto 排隊 private eth mail 記錄 所有江湖偶遇,都是宿命相逢 ----《逆水寒》，只是覺得文案不錯，就用了。哈哈！ 一.設計原則： 單一職責原則（SRP）：任何一個對象都應給只有一個單獨的職責(“低耦合，高內聚”)裏氏替換原則（

【Java-POJO-設計模式】JavaEE中的POJO與設計模式中多型繼承的衝突

最近看《重構》談到利用OO的多型來優化 if else 和 switch 分支語句，但是我發現OO語法中的多型在使用框架的JavaEE中是無法實踐的。對此，我感到十分的疑惑，加之之前專案中有個“狀態模式”類的模組被頻繁改動的需求折磨要死，又去看了《設計模式》。《設計模式》中也是強調，使

JAVA版23種設計模式綜合專案（實戰），設計模式綜合應用的

加入組合模式 n面臨的問題   分析前面直譯器模式的實現，會發現對於客戶端而言，並不想要去區分到底是非終結符物件還是終結符物件，只是想要以一個統一的方式來請求解析。   該怎麼解決這個問題呢？ n n用組合模式來解決   n組合模式基礎回顧  初識組合模式 n定義 &n

設計模式在開發中的應用 -- 代理模式

代理模式 代理是一種模式，提供了對目標物件的間接訪問方式，即通過代理訪問目標物件。如此便於在 實現的基礎上增加額外的功能操作，前攔截，後攔截等，以滿足自身的業務需求，同時代理模式 便於擴充套件目標物件功能的特點也為多人所用。 靜態代理 靜態代理的實現比較簡

php 運用設計模式：觀察者模式，設計電商平臺支付成功程式|Github倉庫

前（fei）言(hua) 在支付程式中，大型專案的維護，如果沒有運用到設計模式，面向過程的程式設計，order程式會日益增加，程式看上去雜亂無章，今天寫了一個小demo ，之前沒有運用過觀察者模式的小夥伴們，可以瞭解一下。 學到什麼 學會了這種設計模式，會讓你的程式碼清晰明瞭

設計模式以及python中的函式是第一類物件

我本來是想學習一下python中的設計模式，後來發現這可能是一個"偽命題"，有很多書都講解java或C++中的設計模式。但很難找到一本python 為何大量設計模式在動態語言中不適用? A. 有一種比慣用法（idiom）抽象層次高那麼一點點的東西，我們給這種東西起個名字，叫設計模式。 B

.NET領域驅動設計—看DDD是如何運用設計模式顛覆傳統架構

閱讀目錄： 1.開篇介紹 2.簡單瞭解緣由（本文的前期事宜） 3.DomainModel擴充套件性（運用設計模式設計模型變化點） 3.1.模型擴充套件性 3.2.設計模式的使用（苦心專研的設計模式、設計思想可以隨意使用了） 3.3.部分類的使用（封裝內部物件） 3.4.高強度的OO設計（

設計模式--spring原始碼中使用策略模式（Strategy Pattern）

策略模式（Strategy Pattern）中體現了兩個非常基本的面向物件設計的基本原則：封裝變化的概念；程式設計中使用介面，而不是對介面實現。策略模式的定義如下： 定義一組演算法，將每個演算法都封裝起來，並且使它們之間可以互換。策略模式使這些演算法在客戶端呼叫它們的時