談談Java常用類別庫中的設計模式 - Part Ⅲ

概述

本系列上一篇：配接器、模版方法、裝飾器

本文介紹的設計模式：

策略
觀察者
代理

相關縮寫：EJ - Effective Java

Here We Go

策略 （Stragety）

定義：定義演算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶，

場景：當不同的行為堆砌在一個類中，難以避免使用條件陳述句選擇行為時，將這些行為封裝在獨立的策略類中，可以消除條件陳述句；一個系統需要動態地選擇一種演算法時，

型別：行為型

相比之前提到的設計模式，策略的使用更加廣泛，它簡單直觀，作用強大，只要業務中存在同一場景會有不同的處理規則，就可以用到策略，
在Java類別庫中使用最頻繁的策略當屬Comparator，

@FunctionalInterface
public interface Comparator<T> {
    int compare(T o1, T o2);
}

Comparator的角色是抽象策略（abstract stragety），而實作了Comparator的具體排序規則就是具體策略（concrete strategy），

在JDK 1.8的Comparator中還實作了諸多預設方法，例如翻轉排序、空值優先、排序規則鏈等，這里使用了模版方法的思想，

在客戶端代碼中實作好比較演算法，剩下的排序作業，交給類別庫去做即可，

Collections.sort(studentList, new Comparator<Student>() {
            @Override
            public int compare(Student a, Student b) {
                return a.getScore()-b.getScore();
            }
        });

當然在實際生產中使用更簡便易讀的comparing方法，豈不美哉？

Collections.sort(studentList,Comparator.comparing(Student::getScore));

除了Comparator，還有一個典型案例：執行緒池的飽和策略，以下是帶有指定飽和策略的執行緒池構造方法（最后一個入參RejectedExecutionHandler handler就是指定飽和策略）

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              RejectedExecutionHandler handler) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), handler);
    }

飽和策略將在有界佇列被填滿后觸發，我們無需關心策略的具體呼叫，只需專注于如何設計策略使得執行緒池更加健壯，以下是ThreadPoolExecutor提供的四種預設策略中的拋棄最舊策略：

public static class DiscardOldestPolicy implements RejectedExecutionHandler {
        /**
         * Creates a {@code DiscardOldestPolicy} for the given executor.
         */
        public DiscardOldestPolicy() { }

        /**
         * Obtains and ignores the next task that the executor
         * would otherwise execute, if one is immediately available,
         * and then retries execution of task r, unless the executor
         * is shut down, in which case task r is instead discarded.
         *
         * @param r the runnable task requested to be executed
         * @param e the executor attempting to execute this task
         */
        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            if (!e.isShutdown()) {
                e.getQueue().poll();
                e.execute(r);
            }
        }

觀察者 （Observer）

定義：定義一種一對多的依賴關系，讓多個觀察者物件同時監聽某一主題物件，這個主題物件在狀態發生變化時，會通知所有觀察者物件，使它們能夠自動更新自己，

場景：當一個物件的改變需要同時改變其它物件的時候，

型別：行為型

觀察者有一個更著名的名字：發布-訂閱模型（Pub/Sub），在Redis、MQ中的使用非常廣泛，實際上JDK在1.0版本就撰寫了觀察者的支持類，

觀察者需要實作Observer介面，在主題通知時將呼叫updae方法更新觀察者自己的狀態，

public interface Observer {
    void update(Observable o, Object arg);
}

主題物件已經被JDK實作，被觀察者發生變化時呼叫notifyObservers通知觀察者，觀察者佇列由系統維護，（類別庫開發較早且沒有維護，觀察者集合仍然使用Vector，）

public class Observable {
    private boolean changed = false;
    private Vector<Observer> obs;

    public Observable() {
        obs = new Vector<>();
    }

    public synchronized void addObserver(Observer o) {
        if (o == null)
            throw new NullPointerException();
        if (!obs.contains(o)) {
            obs.addElement(o);
        }
    }

    public void notifyObservers(Object arg) {
        /*
         * a temporary array buffer, used as a snapshot of the state of
         * current Observers.
         */
        Object[] arrLocal;

        synchronized (this) {
            if (!changed)
                return;
            arrLocal = obs.toArray();
            clearChanged();
        }

        for (int i = arrLocal.length-1; i>=0; i--)
            ((Observer)arrLocal[i]).update(this, arg);
    }
    
    ...省略其它方法
}

值得一提的是，通知觀察者的方法notifyObservers在盡力縮小鎖粒度：因為觀察者執行變更的代碼主題物件無法控制，此段時間不需要也不應該持有主題物件的鎖，于是這里加鎖復制了一個當前觀察者佇列的快照，在執行通知前釋放鎖，遵循了避免過渡同步[EJ Item 79]的原則，

代理 （Proxy）

定義：為其它物件提供一種代理以控制對這個物件的訪問，

場景：為一個物件在不同的地址空間提供區域代表，隱藏一個物件存在于不同地址空間的事實；控制真實物件訪問時的權限；呼叫真實物件時，代理可以附加其它邏輯，

型別：結構型

代理的實作與裝飾器的實作：復合-轉發 基本相同，需要代理類繼承公共介面，并持有被代理類的實體進行轉發，所以二者在結構和功能上非常相似，但比起追加功能，代理強調的是通信控制與屏蔽，
談到Java類別庫中對代理的實踐，那必然是動態代理了，實際上動態代理比代理更加先進：代理本身是結構型設計模式，但在反射的加持下，開發者可以將代理結構延遲到運行時動態構建，這就是動態代理，

        List<Integer> trueList = Collections.emptyList();

        //創建一個代理類，實作特定介面，并將呼叫分發到指定的呼叫處理器上
        List proxyList = (List) Proxy.newProxyInstance(List.class.getClassLoader(),
                new Class[]{List.class}, (proxy, method, args) -> {
                    System.out.println("enter invoke handler");
                    return method.invoke(trueList,args);
                });
        System.out.println(proxyList.size());
        

輸出
----------------
enter invoke handler
0

通過Proxy.newProxyInstance即可創建代理類，代理類實作了指定介面，并且任何方法呼叫將被分發到InvocationHandler上，它持有真正被代理的物件，在執行完代理操作后，便可以將呼叫轉發到真實物件上，
許多成熟框架都使用了動態代理來增強用戶代碼，例如Mybatis的MapperProxy，SpringAOP等等，

參考：

[1] Effective Java - 機械工業出版社 - Joshua Bloch (2017/11)

[2] 《大話設計模式》 - 清華大學出版社 - 陳杰 (2007/12)

標籤：設計模式

上一篇：PHP設計模式—迭代器模式

下一篇：我跪著看完了阿里資深架構師整理分享的分布式系統架構：技術堆疊詳解與進階檔案，直接入職阿里，太值了！