推薦幾個 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 工具,去自動做這種事情。

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

  1. 性能比較差

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

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

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

  1. 運行期做轉換,出錯就代表損失

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

  1. Retrofit ===========

Retrofit 是幹什麼的?

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

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

爲什麼在項目裏用它?

在公司裏,我們有些項目有如下的特點:

  1. 不是基於 Spring 的項目

  2. 需要經常訪問大量的第三方 Http 服務

  3. 訪問 Http 服務的模型通常是異步回調

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

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

  1. 請求參數和 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");
...
  1. 異步回調需要自己搞

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

所以,我們就需要一套能用法簡單,不用我們一直搞拼接參數,自己搞線程管理就能完成對第三方 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

  1. Faker ========

Faker 是幹什麼的?

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

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

爲什麼在項目裏用它?

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

  1. 數據是需要格式的

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

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

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

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

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

  1. 數據的量大

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

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

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

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

與其自己開發,不如用現成的——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

  1. 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