歸還這有什么問題？

Question

在我工作的公司，有一份文檔描述了我們應該在Java中遵循的良好實踐。 其中之一是避免返回this方法，例如：

class Properties {

  public Properties add(String k, String v) {
   //store (k,v) somewhere
     return this;
  }

}

我會有這樣一堂課，所以我能寫：

 properties.add("name", "john").add("role","swd"). ...

我已經多次看過這樣的習慣用法，就像在StringBuilder一樣，並沒有發現它有任何問題。

他們的論證是：

...可能是同步問題的根源或對目標對象狀態的失敗預期。

我想不出這可能是真的情況，你們有誰能舉個例子嗎？

編輯該文檔沒有指定任何有關可變性的內容，因此我沒有看到鏈接調用和執行以下操作之間的差異：

properties.add("name", "john");
properties.add("role", "swd");

我會嘗試與發起人聯系，但我想用我的槍加載，這就是為什么我發布了這個問題。

解決 ：我得與其中一位作者交談，他的初衷顯然是為了避免釋放尚未准備好的對象，比如在Builder模式中，並解釋說如果在調用之間發生上下文切換，則對象可能在無效的狀態。 我認為這與返回this無關，因為你可能會犯同樣的錯誤，一個接一個地調用方法，並且更多地與正確地同步構建過程有關。 他承認該文件可能更加明確，並將很快修改。 勝利是我的/我們的！

Answer 1

我的猜測是他們反對可變狀態（通常是正確的）。 如果您沒有設計返回this流程的fluent接口，而是返回具有已更改狀態的對象的新不可變實例，則可以避免同步問題或者沒有"failed expectations about the states of target objects" 。 這可能解釋了他們的要求。

Answer 2

這種做法唯一嚴肅的基礎是避免可變對象; 批評它“混亂”並導致“失敗的期望”是相當薄弱的。 一個人不應該在沒有熟悉其語義的情況下使用對象，並且只是為了滿足那些選擇不讀Javadoc的人而強制執行A​​PI的約束根本不是一個好習慣 - 特別是因為，正如你所注意到的，返回this以實現流暢的API設計是Java中的標准方法之一，實際上是一個非常受歡迎的方法。

Answer 3

我認為有時這種方法非常有用，例如在'builder'模式中。

我可以說，在我的組織中，這種事情是由聲納規則控制的，我們沒有這樣的規則。

另一個猜測是，項目可能是在現有代碼庫的基礎上構建的，這是一種遺留限制。

所以我在這里建議的唯一一件事就是和寫這篇文章的人交談:)

希望這可以幫助

Answer 4

我認為在某些情況下使用該模式是完全可以接受的。

例如，作為Swing開發人員，我經常使用GridBagLayout來發揮它的優勢和靈活性，但任何曾經使用它的人（在犯罪GridBagConstraints中都是它的伙伴）都知道它可能非常冗長且不易閱讀。

我在網上看到的一個常見的解決方法（我使用的是）是GridBagConstraints（GBConstraints）的子類，它為每個不同的屬性都有一個setter，每個setter返回它。 這允許開發人員根據需要鏈接不同的屬性。

生成的代碼大小約為1/4，並且對於可能不熟悉使用GridBagConstaints的臨時開發人員來說，可讀/可維護性更強。