前言
由於性格原因，筆者很難沉下心來進行嚴肅的系統學習，總是喜歡折騰一些奇淫技巧，非常喜歡程式碼設計，扣程式碼的細節，所以本次分享一下我所知道的如何寫最少的程式碼的小技巧，如果你有更好的方案，歡迎在評論區留言，方案很棒的話，加我微信，為你送上冬天的一杯奶茶~
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);
}
過載可以讓我們的方法呼叫方式變得豐富多彩，在語義明確的情況下，寫程式碼有如神助，配合函數語言程式設計，可以讓工具類或者底層介面的能力大大增強。
同時，當我們需要調整某一個方法邏輯時，也可以使用繼續過載的方式，將影響面降到最小，儘量不動其他模組的程式碼。
終極：從設計模式到抽象
與其說是如何寫最少的程式碼，不如說是：如何只寫真正有價值的程式碼。
面對這種問題的時候，我們第一反應肯定就是設計模式了，例如上文的泛型章節提到的模板方法模式，小小的推薦一下我之前的文章：
通過良好的設計模式或者其變形體，我們可以得到高內聚低耦合的程式碼，這是一個非常好的思路。
另一個思路，所有人都認同一點：程式 = 演算法 + 資料結構，選擇好正確的資料結構可以事倍功半，比如說我們做類似資料夾需求的時候，會想到使用連結串列或者樹結構，在做如：如何高效的給使用者傳送生日簡訊時會想到用堆結構（用當前時間對比堆中的最大值，滿足則繼續迭代，減少遍歷）等等。
這其實都是抽象，或深或淺而已，我最開始學習Java的時候，老師會說一句話：萬物皆為物件，我們來看看上面的技巧各自對應著什麼？
- 多返回值：封裝物件 + 泛型約束
- 泛型：封裝物件的公共介面，高度抽象
- 函式式方法：把方法當作一個物件
- 過載：物件方法（行為）的不斷演化
所以如何只寫真正有價值的程式碼？官方一點的話就是：把變化的抽象出來，那麼到底該怎麼抽？
這就需要我們一點點的去探索了，畢竟奇淫技巧只是小道爾，不過我會一直探索下去。
最後
如果你覺得這篇內容對你有幫助的話：
- 當然要點贊支援一下啦~
- 另外，搜尋並關注公眾號「是Kerwin啊」，一起在技術的路上走下去吧~ ?