推薦幾個 Java 開源類庫，超好用，遠離 996！

今天給大家分享幾個 Java 的開源類庫，親測非常好用！

有了它們之後，你就可以和很多重複勞動說再見了。

1. MapStruct

MapStruct 是幹什麼的？

MapStruct 是個代碼產生器，它能直接根據註解生成 Java 對象對應的轉換器。

比如，直接把一個 A 類型的 Java 對象，給轉成 B 類型的 Java 對象，只需要在他們之間配置上字段之間的映射關係即可。

爲什麼在項目裏用它？

現在隨便一個項目都是多層的，尤其是 Web 項目，經常需要在多層之間做對象模型轉換，比如 DTO 轉換成 BO。

DTO（Data Transfer Object）：數據傳輸對象，Service 向外傳輸的對象。
BO（Business Object）：業務對象，由 Service 層輸出的封裝業務邏輯的對象。

但是這種轉換工作就像是小時候，老師罰我們抄寫名人名言 100 遍一樣，十分枯燥，還容易出錯。

像這樣：

public class CarMapper {
    CarDto carDoToCarDto(Car car) {
        CarDto carDto = new CarDto();
        carDto.setCarId(car.getCarId());
        carDto.setWheel(car.getWheel());
        carDto.setCarType(car.getCarType());
        carDto.setCarColor(car.getCarColor());
        ......
    }

}

要是 Car 有幾十個字段，像 Car 一樣的又有幾十個類，你可以想一下，這種繁瑣程度。

在 MapStruct 之前，我們都是通過 Apache 或者 Spring 的 BeanUtils 工具，去自動做這種事情。

但是這類工具有兩個問題：

性能比較差

性能差主要是 Apache 的 BeanUtils 這套東西，它每次都要針對字段，做是否可讀寫的檢查，還要根據字段生成對應的 PropertyDescriptor。

這些嚴重影響了它的性能，所以，在阿里 Java 手冊裏，也不推薦用它。

Spring 的 BeanUtils，雖然精簡了很多 Apache 的 BeanUtils 的讀寫檢查以及對應的屬性信息記錄，但是它依然是通過反射調用，而且是大量反射調用。這種性能也不能令人滿意。

運行期做轉換，出錯就代表損失

BeanUtils 這類工具，有個統一的名稱，叫做 Java 對象映射框架。

它們大部分的實現都是在運行期去執行代碼，然後在 Java 對象之間去拷貝對應的值。

運行期間做這種事兒，有個最大的問題——整個項目啓動運行後，才能發現錯誤。比如，轉換的時候，類型不一致導致報錯。

對於此種情況，咱們大家都知道，這事兒就像開業酬賓沒搞好，變成了開業仇賓……

如果能寫完代碼，編譯的時候就發現問題，這種損失就可以避免了。

MapStruct 的引入就是爲了解決以上這兩個問題。

MapStruct 首先是個代碼產生器，它是根據註解，去產生一個專門用來轉換的工具類，這個工具類，就像我們自己寫的 Java 類一樣，可以直接被使用，這樣就避免了反射。

同時，它產生的轉換類也特別簡單，就是默認會在兩個類型的 Java 對象之間，拷貝同名屬性的值。

如果有了配置，屬性不同名也可以拷貝。所以它的性能很好。

示例代碼如下：

@Mapper
public interface CarMapper {

    CarMapper INSTANCE = Mappers.getMapper( CarMapper.class );

    @Mapping(target = "seatCount", source = "numberOfSeats")
    CarDto carBoToCarDto(Car car);
}

MapStruct 由於是個代碼產生器，就帶來了個巨大的好處，就是這傢伙是在編譯階段就會生成對應的類，所以，如果有了類似類型轉換不過去的問題，直接就編譯報錯了，根本等不到運行才發現。這樣的話，就不會造成什麼損失，這真是件十分 Nice 的事情。

代碼庫地址

https://github.com/mapstruct/mapstruct

2. Retrofit

Retrofit 是幹什麼的？

Retrofit 就是一套 Http 客戶端，可以用來訪問第三方的 Http 服務。

比如，咱們代碼裏想調用一個 Http 協議的 URL，就可以用它來訪問這個 URL，獲取響應結果。

爲什麼在項目裏用它？

在公司裏，我們有些項目有如下的特點：

不是基於 Spring 的項目
需要經常訪問大量的第三方 Http 服務
訪問 Http 服務的模型通常是異步回調

以前的時候，我們訪問 Http 服務，都是直接用的 HttpClient。

可是吧，HttpClient 用起來實在夠麻煩的。主要也存在兩個問題：

請求參數和 URL 拼接實在繁瑣

請求參數和 URL 拼接實在是太煩人了。你想想，每調用一個接口，就需要自己去拼接參數，有的 URL，甚至十幾二十個參數需要拼接。

拼接這事兒簡單、枯燥、重複，還沒有技術含量，但是工作量卻不小，時間真的算浪費了。

URIBuilder uriBuilder = new URIBuilder(uriBase);
uriBuilder.setParameter("a", "valuea");
uriBuilder.setParameter("b", "valueb");
uriBuilder.setParameter("c", "valuec");
uriBuilder.setParameter("d", "valued");
uriBuilder.setParameter("e", "valuee");
uriBuilder.setParameter("f", "valuef");
uriBuilder.setParameter("g", "valueg");
uriBuilder.setParameter("h", "valueh");
uriBuilder.setParameter("i", "valuei");
...

異步回調需要自己搞

異步回調這種模型不好處理，主要就是需要自己去搞線程池，還要對線程池管理，還要考慮出錯的重試之類的容錯問題，實在麻煩。

所以，我們就需要一套能用法簡單，不用我們一直搞拼接參數，自己搞線程管理就能完成對第三方 Http 服務訪問的庫。

其實我們也想過用 Feign 這套框架的。但是，這套東西和 Spring 綁定的太緊了。如果離開 Spring，它的一些功能就沒法簡單的通過註解直接使用，必須自己寫代碼調用。

而且，Feign 要實現異步回調方式使用，尤其在協程方面，還是需要自己開發。

這時候，Retrofit 就跳進了我們的選型裏。

Retrofit 的模型裏，異步回調模型它支持的很好，我們只需要實現一個 Callable 就夠了。

並且最清爽的是，它和 Spring 沒什麼關係。

Retrofit retrofit = new Retrofit.Builder()
        .baseUrl("http://xxx.example.com/")
        .build();

public interface BlogService {
    @GET("blog/{id}")
    Call<ResponseBody> getBlog(@Path("id") int id);
}

BlogService service = retrofit.create(BlogService.class);

Call<ResponseBody> call = service.getBlog(2);
// 用法和OkHttp的call如出一轍,
// 回調
call.enqueue(new Callback<ResponseBody>() {
    @Override
    public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {
        try {
            System.out.println(response.body().string());
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void onFailure(Call<ResponseBody> call, Throwable t) {
        t.printStackTrace();
    }
});

你看，只需要寫上這些代碼，我們就不需要操心惱人的 Url 拼接和異步回調的管理問題了。全交給了 Retrofit，着實推薦。

代碼庫地址

https://github.com/square/retrofit

3. Faker

Faker 是幹什麼的？

Faker 是專門用來產生各種假數據的輔助工具庫。

比如，你想產生個和真實數據一樣的有姓名、有地址的用戶。

爲什麼在項目裏用它？

我們經常需要造數據去測試，但是，如果沒有工具輔助，我們自己造數據，存在一些問題。

數據是需要格式的

很多關於項目，都需要一些格式上儘量能模仿真實世界的數據。

比如，國內用戶的姓名，大部分都是兩字、三字的姓名，叫王大，就不能叫王 da 這種。

又比如，國內的地址是 xx 市 xx 區 xx 街道 xx 號這種的，就不能胡寫一個幾個沒意義的漢字來當地址。

用貼近真實格式的數據，一來可以測出我們對用戶的數據解析是否存在問題，二來可以測出數據庫內的字段長度是否沒問題。

所以，格式對產生出可靠地測試結果，是很重要的。

數據的量大

有的測試數據量都是上十萬、百萬的，這些量級的數據並不是只會產生一次。

甚至幾乎每個項目，每個項目的每次測試，可能都會需要新的數據，需要能源源不斷地產生出來。

更甚至的是，有時候還想要根據我們的要求，在恰當的時候，產生某種關係的數據，或者以某些特定頻率產生。比如，兩秒後產生一次數據；比如，產生一批姓王的數據。

以上這三種要求綜合起來，要是我們自己造數據，那真是要了命了。

與其自己開發，不如用現成的——Faker 庫被我們找到了。

Faker 庫可以創造三百多種數據，而且還很容易對它進行擴展改造，去產生更多的貼合我們需求的數據。

Faker faker = new Faker();

String name = faker.name().fullName(); // Miss Samanta Schmidt
String firstName = faker.name().firstName(); // Emory
String lastName = faker.name().lastName(); // Barton

String streetAddress = faker.address().streetAddress(); // 60018 Sawayn Brooks Suite 449

幾行代碼，我們需要的一個用戶就有了。

用上 Faker 後，小夥伴們紛紛表示 “有更多的時間摸魚了”。

代碼庫地址

https://github.com/DiUS/java-faker

4. Wiremock

Wiremock 是幹什麼的？

Wiremock 是一個可以模擬服務的測試框架。

比如，你想測試訪問阿里的支付相關接口的代碼邏輯，就可以用它來做測試。

爲什麼在項目裏用它？

比如，我們需要調用銀行接口去做資金業務，調用微信接口去做微信登錄…… 這些調用第三方服務的測試存在一個問題：

即太過依賴對方的平臺。假如對方平臺限制了一些 IP，或者限制了訪問頻率，又或者就是服務出現了維護，都會影響我們自身的功能測試。

爲了解決上述問題，在之前，我們需要自己寫代碼模仿第三方的接口，等我們自己全部測試沒問題了，再去和第三方聯調。對於這種模擬出來的接口，我們稱作擋板。

可是，這種方式是個苦活，沒人願意幹。因爲每接入一個第三方，可能都需要做擋板。辛苦做個擋板，就是單純爲了測試。如果第三方的接口做了改造，你這邊還得跟着改。

大家可以想想，換成你自己，你願意做這麼件事兒嗎？

這時候，Wiremock 的價值就體現出來了。有了 Wiremock，擋板這種東西就再也不存在了，直接在單元測試裏模擬測試即可，像這樣：

WireMock.stubFor(get(urlPathMatching("/aliyun/.*"))
                .willReturn(aResponse()
                        .withStatus(200)
                        .withHeader("Content-Type", APPLICATION_JSON)
                        .withBody("\"testing-library\": \"WireMock\"")));

CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet request = new HttpGet(String.format("http://localhost:%s/aliyun/wiremock", port));
HttpResponse httpResponse = httpClient.execute(request);
String stringResponse = convertHttpResponseToString(httpResponse);

verify(getRequestedFor(urlEqualTo(ALIYUN_WIREMOCK_PATH)));
assertEquals(200, httpResponse.getStatusLine().getStatusCode());
assertEquals(APPLICATION_JSON, httpResponse.getFirstHeader("Content-Type").getValue());
assertEquals("\"testing-library\": \"WireMock\"", stringResponse);

代碼庫地址

https://github.com/wiremock/wiremock

結語

雖然 Java 有很多遭人詬病的地方，但是 Java 最重要的優點之一，就是它的生態，有其琳琅滿目的各種工具類庫。

希望大家都 “懶” 一點，不要埋頭去做無效的苦幹，不要自己造輪子，你要相信：

你遇到的問題，基本已經有很多人遇到過了，而且已經被牛人給解決了，把輪子都給你造好了。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/yC07aEVtiZXC0qVrwV5BCA

1. MapStruct

2. Retrofit

3. Faker

4. Wiremock

結語

猜你喜歡