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

時間 2020-12-13

標籤 html 算法設計模式 app 框架 less ide this 線程設計欄目 Java 简体版

原文原文鏈接

概述

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

本文介紹的設計模式：算法

策略
 觀察者
 代理設計模式

相關縮寫：EJ - Effective Javaapp

Here We Go

策略（Stragety）

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

場景：當不一樣的行爲堆砌在一個類中，難以免使用條件語句選擇行爲時，將這些行爲封裝在獨立的策略類中，能夠消除條件語句；一個系統須要動態地選擇一種算法時。less

類型：行爲型ide

相比以前提到的設計模式，策略的使用更加普遍，它簡單直觀，做用強大，只要業務中存在同一場景會有不一樣的處理規則，就能夠用到策略。
在Java類庫中使用最頻繁的策略當屬Comparator。this

@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等等。