流利的接口 （最初由Martin Fowler 創造）是一種非常方便的與OOP中的對象進行通信的方式。 它使他們的外墻更易于使用和理解。 但是，它破壞了它們的內部設計，使它們更難以維護。 Marco Pivetta在他的博客文章Fluent Interfaces is Evil中說了幾句話； 現在我加幾分錢。

唐尼·布拉斯科（1997）

讓我們看一下我自己的庫jcabi-http ，它是幾年前創建的，當時我認為流暢的接口是一件好事。 這是您使用庫發出HTTP請求并驗證其輸出的方式：

String html = new JdkRequest("https://www.google.com").method("GET").fetch().as(RestResponse.class).assertStatus(200).body();

這種便捷的方法鏈接使代碼簡短明了，對吧？ 是的，表面上確實如此。 但是，包括JdkRequest在內的庫類的內部設計遠非優雅。 最大的問題是它們很大，而且

難
無法擴展它們而不擴大它們。

例如，現在JdkRequest具有方法method() ， fetch()和其他一些方法。 需要新功能時會發生什么？ 添加它的唯一方法是通過添加新方法來擴大類的范圍，這是我們危害其可維護性的方式。 例如， 在這里 ，我們添加了multipartBody() ， 在這里我們添加了timeout（） 。

在jcabi-http中收到新功能請求時，我總是感到害怕。 我了解這很可能意味著向Request ， Response和其他已經膨脹的接口和類添加新方法。

我實際上試圖在庫中做一些事情來解決這個問題，但這并不容易。 查看此.as(RestResponse.class)方法調用。 它所做的是用RestResponse裝飾一個Response ，以便使其方法更豐富。 我只是不想讓Response包含50多種方法，就像許多其他庫一樣。 這是它的作用（這是偽代碼）：

class Response {RestResponse as() {return new RestResponse(this);}// Seven methods } class RestResponse implements Response {private final Response origin;// Original seven methods from Response// Additional 14 methods }

如您所見，我沒有將所有可能的方法添加到Response ，而是將它們放置在補充修飾符RestResponse ， JsonResponse ， XmlResponse 等中 。 它有幫助，但是要使用Response類型的中心對象編寫這些裝飾器，我們必須使用“ ugly”方法as() ，該方法as()很大程度上依賴于Reflection和類型轉換 。

流利的接口意味著大型類或某些丑陋的解決方法。

換句話說，流暢的界面意味著大型類或一些丑陋的解決方法。 當我寫有關Streams API和接口Stream的文章時 ，我曾提到過這個問題，它非常流暢。 有43種方法！

這是流暢接口的最大問題-它們迫使對象變得巨大。

流利的接口非常適合其用戶，因為所有方法都在一個地方，并且類的數量非常少。 使用它們很容易，尤其是在大多數IDE中使用代碼自動完成功能時。 它們也使客戶端代碼更具可讀性，因為“流利的”結構看起來類似于純英語（aka DSL ）。

沒錯！ 但是，它們對對象設計造成的損害是價格過高。

有什么選擇？

我建議您改為使用裝飾器和智能對象 。 如果現在可以做的話，這就是我設計jcabi-http的方法：

String html = new BodyOfResponse(new ResponseAssertStatus(new RequestWithMethod(new JdkRequest("https://www.google.com"),"GET"),200) ).toString();

這與上面的第一個代碼段中的代碼相同，但是它更加面向對象。 當然，此代碼的明顯問題是IDE無法自動完成幾乎所有操作。 同樣，我們將不得不記住許多類的名稱。 對于那些習慣了流利界面的人來說，該結構看起來很難閱讀。 此外，它與DSL的想法相距甚遠。

流暢的界面對用戶有利，但對開發人員不利。 小對象對開發人員有好處，但難以使用。

但是，這里是好處列表。 首先，每個對象都很小，非常有凝聚力，并且它們都是松散耦合的，這在OOP中是顯而易見的優點。 其次，向庫中添加新功能就像創建新類一樣容易。 無需接觸現有課程。 第三，由于類很小，因此簡化了單元測試。 第四，所有類都是不可變的，這在OOP中也很明顯 。

因此，有用性和可維護性之間似乎存在沖突。 流利的接口對用戶有利，但對庫開發人員則不利。 小對象對開發人員有好處，但難以理解和使用。

似乎是這樣，但前提是您已經習慣于大型類和過程編程。 對我來說，大量的小班學習似乎是一種優勢 ，而不是缺點。 即使我不確定確切的類最適合我，內部清晰，簡單且易讀的庫也更易于使用。 即使沒有代碼自動完成功能，我也可以自己解決，因為代碼很干凈。

另外，我經常發現自己對在代碼庫內部或通過對庫的拉取請求擴展現有功能感興趣。 如果我知道所引入的更改是孤立的并且易于測試，那么我對此更感興趣 。

因此，我再也沒有流暢的界面，只有對象和裝飾器。

翻譯自: https://www.javacodegeeks.com/2018/03/fluent-interfaces-are-bad-for-maintainability.html

總結

以上是生活随笔為你收集整理的流利的接口不利于维护的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。