2. 程式人生 > 實用技巧 >如何利用設計模式改善業務程式碼？

如何利用設計模式改善業務程式碼？

阿新 • • 發佈：2020-11-04

在業務部門的開發中，大多數的我們在完成的業務的各種需求和提供解決方案，很多場景下的我們通過 CRUD 就能解決問題，但是這樣的工作對技術人的提升並不多，如何讓自己從業務中解脫出來找到寫程式碼的樂趣呢，我做過一些嘗試，使用設計模式改善自己的業務程式碼就是其中的一種。讓程式碼變得更加簡潔和提升健壯性，從程式碼中尋找一些歡樂。



前言

阿里優秀的人很多，他們身上都有著共同的特質，就是看問題的思考能力，讓我最佩服的是思考力強的人，對事情有深入見解和觀點的人，大多數人還是停留在表面看問題，很多禁錮在思想裡逃不出來，古人說，立德立言立功為三不朽，立言就是思考力和認知力，人和人的差異，在長久的職場中或者生活中，除去運氣外，其實就是認知和思考力的差異。所以除去繁瑣的工作後，如何在有限的時間從程式碼中尋找歡樂，需要提高的是思考和規劃能力。

責任鏈設計模式

▐模式定義



責任鏈模式(Chain of Responsibility Pattern), 是行為型設計模式之一。這種模型結構有點類似現實生活中鐵鏈，由一個個鐵環首尾相接構成一條鏈，如果這種結構用在程式設計領域，則每個節點可以看做一個物件，每個物件有不同的處理邏輯，將一個請求從鏈的首端發出，沿著鏈的路徑依次傳遞每個節點物件，直到有物件處理這個請求為止，我們將這樣一種模式稱為責任鏈模式。

▐適用場景

適用於多節點的流程處理，每個節點完成各自負責的部分，節點之間不知道彼此的存在，比如 OA 的審批流，Java Web 開發中的 Filter 機制。

  • 多個物件可以處理同一個請求，但具體由哪個物件處理則在執行時動態決定。

  • 在請求處理者不明確的情況下向對個物件中的一個提交一個請求。

  • 需要動態處理一組物件處理請求。

  • 　　ptional<Integer> max www.jintianxuesha.com= list.stream(www.huiyinpp3zc.cn).max((a, b) -> a - b);
    　　
    　　System.out.println(max.get(www.haoranjupt.com)); www.fudayulpt.cn// 6
    　　
    　　//求集合的最小值
    　　
    　　System.out.println(list.stream( www.jubooyule.com ).min((www.baihua178.cn b) -> a-b).get()); // 1
    　　
    　　System.out.println(www.jucaiyle.cn list.stream(www.tengyueylzc.cn).count(www.baihuayllpt.cn));//
    　　
    　　String str =www.qitianylezc.cn"11,22,33,44,55";
    　　
    　　System.out.println(Stream.of(str.split(www.longtenghai2.com",")).mapToInt(www.wujiu5zhuce.cn-> Integer.valueOf(x)).sum());
    　　
    　　System.out.println(Stream.of(str.split("www.lanboylgw.com,")).mapToInt(Integer::valueOf).sum());
    　　
    　　System.out.println(Stream.of(str.split(www.shentuylzc.cn",")).map(x -> Integer.valueOf(x)).mapToInt(x -> x).sum());
    　　
    　　System.out.println(Stream.of(str.split(www.xingyunylpt.com",")).map(Integer::valueOf).mapToInt(x -> x).su

舉一個生活中的例子，比如你突然想世界那麼大你想去看看，但是處於現實的你還不能丟了工作，得到請假的OA申請，請假天數如果是半天到1天，可能直接主管批准即可；如果是1到3天的假期，需要部門經理批准；如果是3天到30天，則需要總經理審批；大於30天，正常不會批准。這種簡單的流程即可試用於我們當前業務場景。


▐實踐經驗


業務流程很簡單：

  • 打電話登出信用卡

  • 工作人員登出信用卡

登出信用卡有個背景是這樣的，如果信用卡存在賬單未還清，存在溢位款，存在特殊年費未使用等情況是不允許登出信用卡的，鑑於此，我們在登出之前加了一套是否允許登出的檢驗邏輯。

大體如下：

  • 是否存在賬單未還清，比如有已出賬單未還清，有未出賬單未還清，有年費管理費等未還清等。

  • 是否存在溢位款多餘的錢。

  • 是否存在高額積分未使用，需使用者確認放棄積分等。

針對這幾類情況建立了三類過濾器，分別是：

  • UserLogoutUnpaidBillsLimitFilter：是否存在未還清金額。

  • UserLogoutOverflowLimitFilter：是否存在溢位款。

  • UserLogoutGiveUpPointsLimitFilter：是否放棄高額金額。

判斷邏輯是先通過UserLogoutUnpaidBillsLimitFilter判斷當前使用者是否可以登出信用卡。如果允許繼續由 UserLogoutOverflowLimitFilter 判斷是否存在溢位款，是否可以登出信用卡；如果沒有溢位款繼續由UserLogoutGiveUpPointsLimitFilter 判斷當前使用者是否存在高額積分，前面三條判斷，只要有一個不滿足就提前返回。

   public boolean canLogout(String userId) {        //獲取使用者資訊        UserInfo userInfo = getUserInfo(userId);
        // 構造登出信用卡限制過濾器鏈條        LogoutLimitFilterChain filterChain = new LogoutLimitFilterChain();        filterChain.addFilter(new UserLogoutUnpaidBillsLimitFilter());        filterChain.addFilter(new UserLogoutOverflowLimitFilter());        filterChain.addFilter(new UserLogoutGiveUpPointsLimitFilter());        boolean checkResult = filterChain.doFilter(filterChain, userInfo);
        //filterChain.doFilter方法        public boolean doFilter (LogoutLimitFilterChain filterChain, UserInfo userInfo){            //迭代呼叫過濾器            if (index < filters.size()) {                return filters.get(index++).doFilter(filterChain, userInfo);            }        }    }
    //UserLogoutUnpaidBillsLimitFilter.doFilter方法    public boolean doFilter(LogoutLimitFilterChain filterChain, UserInfo userInfo) {        //獲取使用者當前欠款金額        UserCardBillInfo userCardBillInfo = findUserCardBillInfo(userInfo);
        // 判斷當前卡使用者是否允許消費        if (userCardBillInfo != null) {            if ((!CAN_LOGOUT.equals(userCardBillInfo.getEnabledLogout()))) {                return false;            }        }        //其餘情況，繼續往後傳遞        return filterChain.doFilter(filterChain, memberInfo, consumeConfig);    }
    //UserLogoutOverflowLimitFilter.doFilter方法    public boolean doFilter(LogoutLimitFilterChain filterChain, UserInfo userInfo) {        //判斷使用者是否存在溢位款        UserCardDeposit userCardDeposit = findUserCardDeposit(userInfo);
        // 判斷當前卡使用者是否允許消費        if (userCardDeposit != null) {            if (userCardDeposit.getDeposit() != 0) {                return false;            }        }        //其餘情況，繼續往後傳遞        return filterChain.doFilter(filterChain, memberInfo, consumeConfig);    }

總結：將每種限制條件的判斷邏輯封裝到了具體的 Filter 中，如果某種限制條件的邏輯有修改不會影響其他條件，如果需要新加限制條件只需要重新構造一個 Filter 織入到 FilterChain 上即可。

責任鏈中一個處理者物件，其中只有兩個行為，一是處理請求，二是將請求轉送給下一個節點，不允許某個處理者物件在處理了請求後又將請求轉送給上一個節點的情況。對於一條責任鏈來說，一個請求最終只有兩種情況，一是被某個處理物件所處理，另一個是所有物件均未對其處理，前一種情況稱該責任鏈為純的責任鏈，對於後一種情況稱為不純的責任鏈，實際應用中，多為不純的責任鏈。


策略設計模式

▐模式定義



策略這個詞應該怎麼理解，打個比方說，我們出門的時候會選擇不同的出行方式，比如騎自行車、坐公交、坐火車、坐飛機等等，這些出行方式，每一種都是一個策略。

再比如我們去逛商場，商場現在正在搞活動，有打折的、有滿減的、有返利的等等，其實不管商場如何進行促銷，說到底都是一些演算法，這些演算法本身只是一種策略，並且這些演算法是隨時都可能互相替換的，比如針對同一件商品，今天打八折、明天滿100減30，這些策略間是可以互換的。

策略模式（Strategy Pattern）是定義了一組演算法，將每個演算法都封裝起來，並且使它們之間可以互換。


▐適用場景

主要是為了消除大量的 if else 程式碼，將每種判斷背後的演算法邏輯提取到具體的策略物件中，當演算法邏輯修改時對使用者無感知，只需要修改策略物件內部邏輯即可。這類策略物件一般都實現了某個共同的介面，可以達到互換的目的。

  • 多個類只有演算法或行為上稍有不同的場景

  • 演算法需要自由切換的場景

  • 需要遮蔽演算法規則的場景


▐實踐經驗

業務流程很簡單：

  • 挑選商品

  • 選擇不同的優惠方式結賬

比如即將到來的雙十一活動某些線下商家舉辦活動，折扣力度如下滿300-80，部分商品5折，根據不同會員等級享受不同的折扣最低7折，週年慶活動可享8折等等。假如這些活動折扣不可同享，那麼如何去實現以及考慮可擴充套件性的話策略模式是一種不錯的選擇。


/** * 抽象折扣策略介面 */
public abstract class DiscountStrategy {  /**   * 計算折扣後的價格    * @param price      原價   * @return           折扣後的價格   */  public abstract CalculationResult getDiscountPrice(Long userId ,BigDecimal price);}

/** * 滿減活動 -- 滿300減80 */public class FullReductionStrategyOne extends DiscountStrategy {    /**     * 計算折扣後的價格     * @param price      原價     * @return     */    @Override    public CalculationResult getDiscountPrice(Long userId ,BigDecimal price) {        if (price.doubleValue() < 300) {            return price;        }        BigDecimal dealPrice= price.subtract(BigDecimal.valueOf(80));        return getCalculationResult(userId,dealPrice);    }}

/** * 部分商品5折 */public class MerchandiseDiscountStrategy extends DiscountStrategy {    /**     * 計算折扣後的價格     * @param price      原價     * @return     */    @Override    public CalculationResult getDiscountPrice(BigDecimal price) {        BigDecimal dealPrice=  price.multiply(BigDecimal.valueOf(0.5));        return getCalculationResult(userId,dealPrice);    }}

/***當有新的需求式，我們只需要新增一個新的介面即可，不需要修改原有的具體策略實現程式碼即可完成。*定義完策略後，我們再定義一個”環境角色”，假設我們這個環境角色就使用價格物件吧*/
public class Price {
    private DiscountStrategy discountStrategy;
    /**     * 定義一個無參構造，用於例項物件     */    private Price(DiscountStrategy discountStrategy) {        this.discountStrategy = discountStrategy;    }
    /**     * 獲取折扣後的價格     *     * @param price 原始價格     * @return     */    public CalculationResult discount(Long userId,BigDecimal price) {        return discountStrategy.getDiscountPrice(userId ,price);    }}


策略模式是一種行為型模式，將演算法的使用和演算法本身分割開，委派給不同的物件管理。策略實現類一般是封裝好的輕量級的演算法，當客戶端（呼叫方）遇到不同的情況時，這些演算法可以根據需要動態地去互相替換。策略的選擇完全是由客戶端進行的，這就要求客戶端必須理解所有的策略實現類，雖然提高了系統的靈活性，但也增加了客戶端的使用難度。策略模式體現了開閉原則——“對擴充套件開放，對修改關閉”。新的策略增加時，不會影響其他類的修改，增加了擴充套件性，對擴充套件開放；只依賴於抽象，而不依賴於具體實現，所以對修改是關閉的。這樣在提高程式碼擴充套件性的同時，也降低了耦合。
總結：將每種通道的推送邏輯封裝到了具體的策略中，某種策略的變更不會影響其他策略，由於實現了共同介面，所以策略可以互相替換，對使用者友好。比如 Java ThreadPoolExecutor 中的任務拒絕策略，當執行緒池已經飽和的時候會執行拒絕策略，具體的拒絕邏輯被封裝到了 RejectedExecutionHandler 的 rejectedExecution 中。

模板設計模式

▐模式定義


模板的價值就在於骨架的定義，骨架內部將問題處理的流程已經定義好，通用的處理邏輯一般由父類實現，個性化的處理邏輯由子類實現。

比如炒土豆絲和炒麻婆豆腐，大體邏輯都是：

1、切菜

2、放油

3、炒菜

4、出鍋

1，2，4 都差不多，但是第 3 步是不一樣的，炒土豆絲得拿鏟子翻炒，但是炒麻婆豆腐得拿勺子輕推，否則豆腐會爛。

▐使用場景

不同場景的處理流程，部分邏輯是通用的，可以放到父類中作為通用實現，部分邏輯是個性化的，需要子類去個性實現。

模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現，但呼叫將以抽象類中定義的方式進行。這種型別的設計模式屬於行為型模式。

▐實踐經驗

還是接著之前商品折扣的例子來說，後期我們新加了兩個需求：

  • 使用者享受不同折扣增加 trace。

  • 使用者享受折扣後是否升級會員等級。

所以現在的流程變成了這樣：

1、trace 開始。

2、計算使用者不同折扣力度。

3、是否允許升級會員等級，如果允許執行升級會員等級邏輯。

4、trace 結束。

其中 1 和 4 是通用的，2 和 3 是個性化的，鑑於此可以在折扣策略之前增加了一層父類的策略，將通用邏輯放到了父類中。

修改後的程式碼如下：

abstract class AbstractDiscountStrategy implements DiscountStrategy{
    @Override    public CalculationResult getDiscountPrice(Long userId ,BigDecimal price) {        //1.構造span        Span span = buildSpan();        //2.具體通道推送邏輯由子類實現        CalculationResult  calculationResult =getCalculationResult(userId,price);        //3.是否允許升級會員等級，如果允許執行升級邏輯        if(!calculationResult.isSuccess() && canUpgrade()){            upgradeLevel(userId,calculationResult);        }
        //4.trace結束        span.finish();        return calculationResult;    } 
    //具體推送邏輯由子類實現    protected abstract CalculationResult getCalculationResult(Long userId,BigDecimal price) ;
    //是否允許升級會員等級由子類實現    protected abstract boolean canUpgrade(Long userId,CallResult callResult);
}

/** * 滿減活動 -- 滿300減80 */public class FullReductionStrategyOne extends AbstractDiscountStrategy {    @Override    protectedCalculationResult getCalculationResult(Long userId,BigDecimal price){        //執行折扣邏輯    }
    @Override    protected  boolean canUpgrade(Long userId,CallResult callResult){        return false    }}

觀察者設計模式

▐模式定義

拍賣的時候，拍賣師觀察最高標價，然後通知給其他競價者競價 這種模式就可以使用觀察者模式。顧名思義，此模式需要有觀察者（Observer）和被觀察者（Observable）兩類角色。當 Observable 狀態變化時會通知 Observer，Observer 一般會實現一類通用的介面。

比如 java.util.Observer，Observable 需要通知 Observer 時，逐個呼叫 Observer 的 update 方法即可，Observer 的處理成功與否不應該影響 Observable 的流程。

▐使用場景

當物件間存在一對多關係時，則使用觀察者模式（Observer Pattern）。比如，當一個物件被修改時，則會自動通知依賴它的物件。觀察者模式屬於行為型模式。

一個物件（Observable）狀態改變需要通知其他物件，Observer 的存在不影響 Observable 的處理結果，Observer 的增刪對 Observable 無感知。

比如 Kafka 的訊息訂閱，Producer 傳送一條訊息到 Topic，至於是 1 個還是 10 個 Consumer 訂閱這個 Topic，Producer 是不需要關注的。

▐實踐經驗

在責任鏈設計模式那塊我通過三個 Filter 解決了登出信用卡限制檢驗的問題，其中有一個 Filter 是用來檢驗使用者積分的，我這裡只是讀取使用者的積分總額和次數，那麼消費次數獲得積分的累加是怎麼完成的呢？

其實累加這塊就用到了觀察者模式，具體來講是這樣，當交易系統收到支付成功回撥時會通過 Spring 的事件機制釋出“支付成功事件”。

這樣負責積分消費次數累加和負責語音播報的訂閱者就會收到“支付成功事件”，進而做各自的業務邏輯。

畫個簡單的圖描述一下：

/**支付回撥處理者*/PayCallBackController implements ApplicationContextAware {     private ApplicationContext applicationContext;
    //如果想獲取applicationContext需要實現ApplicationContextAware介面，Spring容器會回撥setApplicationContext方法將applicationContext注入進來    @Override    public void setApplicationContext(ApplicationContext applicationContext)            throws BeansException {        this.applicationContext = applicationContext;    }
     @RequestMapping(value = "/pay/callback.do")     public View callback(HttpServletRequest request){        if(paySuccess(request){            //構造支付成功事件            PaySuccessEvent event = buildPaySuccessEvent(...);            //通過applicationContext釋出事件，從而達到通知觀察者的目的            this.applicationContext.publishEvent(event);        }     }}/** * 語音播報處理者 * */public class VoiceBroadcastHandler implements ApplicationListener<PaySuccessEvent>{    @Override    public void onApplicationEvent(PaySuccessEvent event) {        //語音播報邏輯    }}
//其他處理者的邏輯類似

總結：觀察者模式將被觀察者和觀察者之間做了解耦，觀察者存在與否不會影響被觀察者的現有邏輯。

裝飾器設計模式

▐模式定義

裝飾器模式（Decorator Pattern）允許向一個現有的物件新增新的功能，同時又不改變其結構。這種型別的設計模式屬於結構型模式，它是作為現有的類的一個包裝。這種模式建立了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。

裝飾器用來包裝原有的類，在對使用者透明的情況下做功能的增強，比如 Java 中的 BufferedInputStream 可以對其包裝的 InputStream 做增強，從而提供緩衝功能。

▐使用場景

在不影響其他物件的情況下，以動態、透明的方式給單個物件新增職責。需要動態地給一個物件增加功能，這些功能也可以動態地被撤銷。當不能採用繼承的方式對系統進行擴充套件或者繼承。希望對原有類的功能做增強，但又不希望增加過多子類時，可以使用裝飾器模式來達到同樣的效果。

▐實踐經驗

有一個咖啡店，銷售各種各樣的咖啡，拿鐵，卡布奇洛，藍山咖啡等，在沖泡前，會詢問顧客是否要加糖，加奶，加薄荷等。這樣不同的咖啡配上不同的調料就會賣出不同的價格。

/*** 抽象類Coffee*/public abstract class Coffee {    /**     * 獲取咖啡得名字     */    public abstract String getName();
    /**     * 獲取咖啡的價格     */    public abstract double getPrice();}
/***利用繼承和組合的結合,現在我們可以考慮設計出一個裝飾類，它也繼承自coffee，*並且它內部有一個coffee的例項物件*/public abstract class CoffeeDecorator implements Coffee {    private Coffee delegate;
    public CoffeeDecorator(Coffee coffee) {        this.delegate = coffee;    }
    @Override    public String getName() {        return delegate.getName();    }
    @Override    public double getPrice() {        return delegate.getPrice();    }}

/***牛奶咖啡的裝飾者模式的案例*/public class MilkCoffeeDecorator extends CoffeeDecorator {    public MilkCoffeeDecorator(Coffee coffee) {        super(coffee);    }
    @Override    public String getName() {        return "牛奶, " + super.getName();    }
    @Override    public double getPrice() {        return 1.1 + super.getPrice();    }}
//其他咖啡的模式類似

/***測試案例 可以通過加入不用內容 咖啡名稱和價格都是不同的*/public class App {    public static void main(String[] args) {        // 得到一杯原始的藍山咖啡        Coffee blueCoffee = new BlueCoffee();        System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());
        // 加入牛奶        blueCoffee = new MilkCoffeeDecorator(blueCoffee);        System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());
        // 再加入薄荷        blueCoffee = new MintCoffeeDecorator(blueCoffee);        System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());
        // 再加入糖        blueCoffee = new SugarCoffeeDecorator(blueCoffee);        System.out.println(blueCoffee.getName() + ": " + blueCoffee.getPrice());    }}

總結：使用裝飾器模式做了功能的增強，對使用者來說只需要做簡單的組合就能繼續使用原功能。裝飾器模式充分展示了組合的靈活。利用它來實現擴充套件。它同時也是開閉原則的體現。如果相對某個類實現執行時功能動態的擴充套件。這個時候你就可以考慮使用裝飾者模式！

橋接設計模式

▐模式定義


橋接模式是一種結構型設計模式，可將一個大類或一系列緊密相關的類拆分為抽象和實現兩個獨立的層次結構，從而能在開發時分別使用。

橋接（Bridge）是用於把抽象化與實現化解耦，使得二者可以獨立變化。這種型別的設計模式屬於結構型模式，它通過提供抽象化和實現化之間的橋接結構，來實現二者的解耦。

▐使用場景

如果一個系統需要在抽象類和具體類之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關係，通過橋接模式可以使它們在抽象層建立一個關聯關係。

抽象部分和實現部分可以以繼承的方式獨立擴充套件而互不影響，在程式執行時可以動態的將一個抽象類子類的物件和一個實現類子類的物件進行組合，及系統需要對抽象類角色和實現類角色進行動態耦合。

一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立進行擴充套件。

對於那些不希望使用繼承或因為多層繼承導致系統的個數急劇增加的系統，橋接模式尤為適用。

▐實踐經驗

效能管理系統中，資料產生後需要經過採集，匯聚，入庫三個流程，使用者才能查詢使用。採集可以是snmp採集，也可以是ems採集；匯聚可以使storm匯聚，也可以是spark匯聚；入庫可以是hdfs入庫，也可以是mppdb入庫。針對不同場景，我們可以靈活選擇不同的採集，匯聚，入庫方式。這種一個功能需要多種服務支援，每種服務又有不同型別的實現，使用橋接模式再適合不過。

橋接模式，顧名思義，就是把每種服務看做一座橋，我們可以根據實際場景選擇不同的橋。上述例子表示資料產生到可以使用之前需要經過三座橋：採集橋->匯聚橋->入庫橋。每座橋可以選擇不同的構造。



/** *  * 採集橋採集服務 * */public abstract class CollectionService{    abstract void execute();    public void run(){        execute();    }}


/** *  匯聚橋  匯聚服務 * */public abstract class AggregationService{    public void run(){        if(null != collectionService)        {            collectionService.run();        }        execute();    }    abstract void execute();    CollectionService collectionService;    public AggregationService(CollectionService collectionService){        this.collectionService = collectionService;    }}

/** *  * 入庫橋   入庫服務 * */public abstract class StoreService{    public void run(){        if(null != aggregationService)        {            aggregationService.run();        }        execute();    }    abstract void execute();    AggregationService aggregationService;    public StoreService(AggregationService aggregationService){        this.aggregationService = aggregationService;    }}


/**** EMS採集橋**/
public class EMSCollectionService extends CollectionService{    @Override    void execute(){        System.out.println("EMS collection.");    }}
/**** SNMP採集橋**/public class SNMPCollectionService extends CollectionService{    @Override    void execute(){        System.out.println("SNMP collection.");    }}

/****  Storm匯聚橋**/public class StormAggregationService extends AggregationService{    public StormAggregationService(CollectionService collectionService){        super(collectionService);    }
    @Override    void execute(){        System.out.println("Storm aggregation.");    }}

/****  Spark匯聚橋**/public class SparkAggregationService extends AggregationService{    public SparkAggregationService(CollectionService collectionService){        super(collectionService);    }
    @Override    void execute(){        System.out.println("Spark aggregation.");    }}

/****  MPPDB匯聚橋**/public class MPPDBStoreService extends StoreService{    public MPPDBStoreService(AggregationService aggregationService){        super(aggregationService);    }
    @Override    void execute(){        System.out.println("MPPDB store.");    }}

/****  HDFS匯聚橋**/public class HDFSStoreService extends StoreService{    public HDFSStoreService(AggregationService aggregationService){        super(aggregationService);    }
    @Override    void execute(){        System.out.println("HDFS store.");    }}


/** *   * 類功能說明:   橋接模式測試 */public class BridgeTest{    public static void main(String[] args){        CollectionService snmpService = new SNMPCollectionService();        AggregationService stormService = new StormAggregationService(snmpService);        StoreService hdfsService = new HDFSStoreService(stormService);        hdfsService.run();    }}

總結：橋接模式可以將系統中穩定的部分和可擴充套件的部分解耦，使得系統更加容易擴充套件，且滿足OCP原則，對呼叫者修改關閉。

淘系技術部-天貓奢侈品團隊
我們是一支支撐天貓奢侈品、品牌客戶、淘寶心選等大店資料化經營解決方案的技術團隊，依託於阿里大中臺推動品牌經營解決方案升級，不斷提升客戶經營的效率，持續提升業務價值賦能業務。

相關推薦

如何利用設計模式改善業務程式碼？

在業務部門的開發中，大多數的我們在完成的業務的各種需求和提供解決方案，很多場景下的我們通過 CRUD 就能解決問題，但是這樣的工作對技術人的提升並不多，如何讓自己從業務中解脫出來找到寫程式碼的樂趣呢，我做過

阿里面試官親述：如何利用設計模式改善業務程式碼

在業務部門的開發中，大多數的我們在完成的業務的各種需求和提供解決方案，很多場景下的我們通過 CRUD 就能解決問題，但是這樣的工作對技術人的提升並不多，如何讓自己從業務中解脫出來找到寫程式碼的樂趣呢，我做過

利用設計模式消除業務程式碼中的 if-else

準備工作：假設這樣的一個業務場景：有一個自動開票的功能需要實現，在程式裡面需要根據賬單的型別執行對應的處理邏輯。

23種 設計模式 java 例項程式碼

技術標籤：學習筆記設計模式javaspring 23種設計模式 文章目錄 *23種設計模式*一、設計模式的6/7 大原則：1）、UML類圖定義2）、UML類圖詳解1. 名稱詳解**依賴(Dependency)****泛化(Generalization)****實現(R

設計模式-模板方法程式碼示範

/** * 類說明：抽象蛋糕模型 */public abstract class AbstractCake {protected abstract void shape();protected abstract void apply();protected abstract void brake();/*模板方法*///public final void run(){/

設計模式七大原則及程式碼示例

七大原則： 單一職責原則； 介面隔離原則； 依賴倒轉原則； 里氏替換原則； 開閉原則ocp；

設計模式：橋接模式及程式碼示例、橋接模式在jdbc中的體現、注意事項

0、背景 加入一個手機分為多種款式，不同款式分為不同品牌。這些詳細分類下分別進行操作。

設計模式：裝飾者模式介紹及程式碼示例 && JDK裡關於裝飾者模式的應用

0、背景 來看一個專案需求：咖啡訂購專案。 咖啡種類有很多：美式、摩卡、義大利濃咖啡；

Python 程式碼設計模式

責任鏈模式 （場景:OA系統，專案審批...） 使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它為止。

PHP設計模式之建造者模式（Builder）程式碼例項大全（二）

目的 建造者是建立一個複雜物件的一部分介面。 有時候，如果建造者對他所建立的東西擁有較好的知識儲備，這個介面就可能成為一個有預設方法的抽象類（又稱為介面卡）。

PHP設計模式之介面卡模式（Adapter） 程式碼例項大全（十）

目的 將某個類的介面轉換成另一個介面以相容，介面卡使得原來因為介面不同而無法一起使用的類可以一起工作。

PHP設計模式之橋樑模式（Bridge）程式碼例項大全（11）

目的 解耦一個物件使抽象與實現分離，這樣兩者可以獨立地變化。 例子 ★官方PHP高階學習交流社群「點選」管理整理了一些資料，BAT等一線大廠進階知識體系備好（相關學習資料以及筆面試題）以及不限於：分散式架構、

PHP設計模式之組合模式（Composite）程式碼例項大全（12）

目的 一組物件與該物件的單個例項的處理方式一致。 示例 form類的例項包含多個子元素，而它也像單個子元素那樣響應 render() 請求，當呼叫 render() 方法時，它會歷遍所有的子元素，呼叫 render() 方法

PHP設計模式之資料對映模式（Data Mapper）程式碼例項大全（13）

目標 資料對映器是一種資料訪問層，用於將資料在永續性資料儲存（通常是一個關係資料庫）和記憶體中的資料表示（領域層）之間進行雙向傳輸。該模式的目標是為了將資料的記憶體表示、持久儲存、資料訪問進行分離。 該

PHP設計模式之裝飾模式（Decorator）程式碼例項大全（14）

目的 動態地為類的例項新增功能 例子 Zend Framework: Zend_Form_Element 例項的裝飾者

PHP設計模式之依賴注入模式（Dependency Injection）程式碼例項大全（15）

目的 實現了鬆耦合的軟體架構，可得到更好的測試，管理和擴充套件的程式碼

PHP設計模式之門面模式（Facade）程式碼例項大全（16）

目的 門面模式的最初目的並不是為了避免讓你閱讀複雜的 API 文件，這只是一個附帶作用。其實它的本意是為了降低耦合性並且遵循 Demeter 定律。

PHP設計模式之享元模式（Flyweight）程式碼例項大全（18）

目的 為了節約記憶體的使用，享元模式會盡量使類似的物件共享記憶體。在大量類似物件被使用的情況中這是十分必要的。常用做法是在外部資料結構中儲存類似物件的狀態，並在需要時將他們傳遞給享元物件。

PHP設計模式之註冊模式（Registry）程式碼例項大全（20）

目的 目的是能夠儲存在應用程式中經常使用的物件例項，通常會使用只有靜態方法的抽象類來實現（或使用單例模式）。需要注意的是這裡可能會引入全域性的狀態，我們需要使用依賴注入來避免它。

PHP設計模式之代理模式（Proxy）程式碼例項大全（19）

目的 為昂貴或者無法複製的資源提供介面。 代理模式（Proxy）為其他物件提供一種代理以控制對這個物件的訪問。使用代理模式建立代理物件，讓代理物件控制目標物件的訪問（目標物件可以是遠端的物件、建立開銷大的物件