[[357385]]

前言

由于性格原因，筆者很難沉下心來進行嚴肅的系統學習，總是喜歡折騰一些奇淫技巧，非常喜歡代碼設計，扣代碼的細節，所以本次分享一下我所知道的如何寫最少的代碼的小技巧。

Java：我想返回多個返回值

秀一下Go的多返回值：

package main 
import "fmt" 
 
// 返回 X + Y 和 X * Y 
func Computer(X, Y int) (int, int) { 
    return X + Y, X * Y 
} 

眾所周知，Java僅支持單一返回值，一般情況下如果需要返回多個對象，我們會根據代碼語義選擇容器或者新建一個新的類，把我們需要的數據包起來。

這樣做有沒有問題?當然沒有問題，但是瑕疵就在于：可能會產生沒啥語義但又不得不存在的中間類，我個人非常討論該類代碼，那么該如何解決這種問題呢?

首先需要認識到，解決方案必須滿足幾個要求：

• 代碼可復用
• 語義要清晰
• 安全

既然如此，我們可以采用泛型來滿足復用、語義清晰的要求，用中間類來滿足代碼安全性的要求，代碼如下：

public class MultipleTwoReturn<A, B> { 
    /** 第一個返回值 **/ 
    private final A first; 
 
    /** 第二個返回值 **/ 
    private final B second; 
 
    public MultipleTwoReturn(A first, B second) { 
        this.first = first; 
        this.second = second; 
    } 
 
    // 省略Get方法 
} 

同時，我們可以依賴于繼承，讓該工具類拓展更多的參數：

public class MultipleThreeReturn<A, B, C> extends MultipleTwoReturn<A, B> { 
 
    /** 第三個返回值 **/ 
    private final C third; 
 
    public MultipleThreeReturn(A first, B second, C third) { 
        super(first, second); 
        this.third = third; 
    } 
} 

測試類：

public class MultipleApp { 
 
    public static void main(String[] args) { 
        MultipleTwoReturn<Integer, String> returnTest = MultipleApp.getReturnTest(); 
        System.out.println(returnTest.getFirst()); 
        System.out.println(returnTest.getSecond()); 
    } 
 
    private static MultipleTwoReturn<Integer, String> getReturnTest() { 
        MultipleTwoReturn<Integer, String> demo = new MultipleTwoReturn<>(0, "Kerwin Demo."); 
        return demo; 
    } 
} 

本質還是普通對象，但是加上泛型后威力劇增!由于在方法定義時就強制了泛型約束，語義非常清晰，同時可以完全杜絕上述的無語義中間類，當然一些必要的，有業務含義的組裝類，不建議使用這種方式。

泛型：我想new一個對象

大家在學Java泛型之初有沒有這種想法?我想利用作為泛型約束，卻需要new一個T，但是Java它new不出來啊 😂

很久之前我在寫一個通用的Java爬蟲接口，里面有一個功能就是傳入目標網頁的即可獲取到針對不同網頁設計的Bean，大概如下所示：

public interface SpiderBeansHandle<T> { 
    /** 獲取Url **/ 
    String getUrl(); 
 
    /** 獲取Cookie **/ 
    String getCookie(); 
 
    /** 獲取CSS selector **/ 
    String getSelector(); 
     
    // .... 
 } 

中間關鍵的一點即如何獲取到這個Bean，那個時候我只有一個想法：new 一個 T

事實證明，我過于天真了 🙄

但是換種思路，既然new不出來，那我就返回一下吧，于是代碼出爐了~

public interface SpiderBeansHandle<T> { 
 
    /** 
     * 獲取Url 
     */ 
    String getUrl(); 
 
    /** 
     * 獲取Cookie 
     */ 
    String getCookie(); 
 
    /*** 
     * 獲取CSS selector 
     */ 
    String getSelector(); 
 
    /*** 
     * 解析Element 
     * @param element  element 
     */ 
    T parseElement(Element element); 
 
    /*** 
     * Get Beans 
     * @param handle  Bean對象 | handle對象 
     * @param <T>     Bean類型 
     * @return        List<Beans> 
     */ 
    static <T> List<T> getBeans(SpiderBeansHandle<T> handle) { 
        List<T> list = new ArrayList<>(); 
        List<Element> elements = SpiderUtils.getElementWithCookie(handle.getUrl(), handle.getSelector(), handle.getCookie()); 
        for (Element element : elements) { 
            T bean = handle.parseElement(element); 
            if (bean != null) { 
                list.add(bean); 
            } 
        } 
        return list; 
    } 
} 

關鍵一步就在于：

/*** 
 * 解析Element 
 * @param element  element 
 */ 
T parseElement(Element element); 

那么這個小技巧有什么用呢?仔細看會不會覺得它像一種設計模式的變形體?沒錯!真相只有一個：模板方法模式

我剛提到了我需要一個處理爬蟲的通用接口，因為簡單爬蟲無非就是拿到url然后請求，解析細節封裝到自身的Bean里，然后獲取一個列表，那么在開發業務代碼的時候類似，肯定有某些場景和需求具有高度的一致性，那么使用這種設計方案即可大大的減少重復代碼~

方法：你到底想干嘛?

咱們在寫代碼的時候有沒有遇到過這種問題?寫了一個工具類方法，但是功能又過于單一，雖說單一原則好吧，但是一個小邏輯寫一堆方法，總感覺不得勁，如何解決咧?

Java8提供的函數式編程即可幫我們一定程度上解決這種問題，如：

// 寫一個獲取文件列表，且判斷是否為txt結尾的工具類方法，新手會這么寫 
public static File getFileWithTxt(String path) throws IOException { 
    File file = new File(path); 
    if (!file.exists()) { 
        throw new IOException("File is not exist."); 
    } 
 
    if (file.getName().endsWith(".txt")) { 
        return file; 
    } 
 
    return null; 
} 

老手一般會把 .txt 作為參數傳入，但是某一天我需要判斷文件大小，文件長度，甚至是文件內容的時候，我該咋辦?再寫N個?

最好的方案即傳入 Predicate 謂詞，讓調用者自定義處理邏輯，然后再把最常用的邏輯基于該方法復寫一下，拓展性Max!代碼如下：

/*** 
 * 文件夾謂詞匹配 
 * @param file          文件 
 * @param predicate     謂詞匹配 
 * @return              List<File> 
 * @throws IOException  IOException 
 */ 
public static List<File> listFilesInDirWithFilter(File file, Predicate<String> predicate) throws IOException { 
 if (!file.exists()) { 
   throw new IOException("File is not exist."); 
     } 
 
 List<File> fileList = new ArrayList<>(); 
 if (file.isDirectory()) { 
  File[] files = file.listFiles(); 
  for (File f : Objects.requireNonNull(files)) { 
   fileList.addAll(listFilesInDirWithFilter(f, predicate)); 
         } 
 } else { 
  if (predicate.test(file.getName())) { 
   fileList.add(file); 
  } 
 } 
 return fileList; 
} 

類似的還比如說處理 IO，直接上代碼：

public static void readLine(BufferedReader br, Consumer<String> handle, boolean close) { 
    String s; 
    try { 
        while (((s = br.readLine()) != null)) { 
            handle.accept(s); 
        } 
    } catch (IOException e) { 
        e.printStackTrace(); 
    } finally { 
        if (close && br != null) { 
            try { 
                br.close(); 
            } catch (IOException e) { 
                e.printStackTrace(); 
            } 
        } 
    } 

方法說你到底想干嘛?!算了，你想干嘛就干嘛吧，請隨意😎~

重載：寫的更多也是為了寫的更少

寫的更多也是為了寫的更少，這句話乍一聽感覺非常矛盾，但是編程經驗比較豐富的小伙伴應該能體會到方法重載的威力，尤其是在寫工具類或者底層接口的時候，建議大家先寫一個大而全的內部方法，然后一點點去根據需要重載它，會有意想不到的好處。

最簡單的例子，如下：

// Root 方法 
private static void readLine(BufferedReader br, Consumer<String> handle, boolean close) { 
    String s; 
    try { 
        while (((s = br.readLine()) != null)) { 
            handle.accept(s); 
        } 
    } catch (IOException e) { 
        e.printStackTrace(); 
    } finally { 
        if (close && br != null) { 
            try { 
                br.close(); 
            } catch (IOException e) { 
                e.printStackTrace(); 
            } 
        } 
    } 
} 
 
// 重載方法一 
public static void readLine(String path, Consumer<String> handle, boolean close) { 
    try { 
        BufferedReader br = new BufferedReader(new FileReader(path)); 
        readLine(br, handle, close); 
    } catch (FileNotFoundException e) { 
        e.printStackTrace(); 
    } 
} 
 
// 重載方法二 
public static void readLine(String path, Consumer<String> handle) { 
 readLine(path, handle, true); 
} 

重載可以讓我們的方法調用方式變得豐富多彩，在語義明確的情況下，寫代碼有如神助，配合函數式編程，可以讓工具類或者底層接口的能力大大增強。

同時，當我們需要調整某一個方法邏輯時，也可以使用繼續重載的方式，將影響面降到最小，盡量不動其他模塊的代碼。

終極：從設計模式到抽象

與其說是如何寫最少的代碼，不如說是：如何只寫真正有價值的代碼。

面對這種問題的時候，我們第一反應肯定就是設計模式了，例如上文的泛型章節提到的模板方法模式，小小的推薦一下我之前的文章：

• 【一起學系列】之模板方法：寫SSO我只要5分鐘
• 設計模式總篇：從為什么需要原則到實際落地

通過良好的設計模式或者其變形體，我們可以得到高內聚低耦合的代碼，這是一個非常好的思路。

另一個思路，所有人都認同一點：程序 = 算法 + 數據結構，選擇好正確的數據結構可以事倍功半，比如說我們做類似文件夾需求的時候，會想到使用鏈表或者樹結構，在做如：如何高效的給用戶發送生日短信時會想到用堆結構(用當前時間對比堆中的最大值，滿足則繼續迭代，減少遍歷)等等。

這其實都是抽象，或深或淺而已，我最開始學習Java的時候，老師會說一句話：萬物皆為對象，我們來看看上面的技巧各自對應著什么?

• 多返回值：封裝對象 + 泛型約束
• 泛型：封裝對象的公共接口，高度抽象
• 函數式方法：把方法當作一個對象
• 重載：對象方法(行為)的不斷演化

所以如何只寫真正有價值的代碼?官方一點的話就是：把變化的抽象出來，那么到底該怎么抽?

這就需要我們一點點的去探索了，畢竟奇淫技巧只是小道爾，不過我會一直探索下去。