可鏈式方法的優點和缺點？

Question

我真的很喜歡鏈接方法的哲學，像jQuery強調在它的庫中。我發現它非常優雅和清晰。

作爲主要的Java開發人員，我一直在想自己爲什麼這種做法不會在這種語言中使用得更多。例如，Collection接口不是以這種方式設計的（用於添加/刪除方法），我發現它非常難過。

有沒有對這種做法有真正的反感，還是隻是沒有足夠的「性感」之前？

Answer 1

Martin Fowler在http://www.martinfowler.com/bliki/FluentInterface.html上將此主題作爲「流暢接口」進行了討論。一個主要的問題是流暢的接口是爲人類設計的，因此像Spring這樣的框架無法理解它們。簡單地使用流暢的接口在某種意義上提供可維護性（可讀性），但在另一個（靈活性）中失去可維護性。

Answer 2

我也非常喜歡這種方法。我能想到的唯一缺點是，在每種方法的末尾「返回」似乎有點尷尬。舉例來說，對於JQuery來說，允許插件有點尷尬，因爲你必須說「確保你不會忘記你的回報!!」但在編譯時沒有好的方法來捕捉它。

Answer 3

唯一的缺點是你鬆了返回類型，所以Chaining對於做事情的操作很好，但對計算事物的操作不太好。

另一個問題是，與鏈接編譯器不能輕鬆地確定內聯的平凡函數調用。但正如我所說，如果你的鏈接操作，而不是計算，那麼編譯器最有可能不會改變任何東西。

Answer 4

JavaScript（或多或少）是一種功能語言，其功能與一等公民一樣。
向對象添加/刪除方法，將函數作爲參數傳遞，這一切對於此語言來說都是很自然的。

另一方面，Java是嚴格的OO，一個功能不能存在於一個類之外。使用繼承，組合和接口是這種語言更自然的方式。

Answer 5

IMO調試很痛苦，因爲您往往沒有中間變量進行檢查。

Answer 6

可連接方法是我們設計工具包中的另一個重要工具。只要確保你不會碰到常見的「我有錘子，因此每個問題都是釘子」設計混亂。

每個設計問題都沒有通過可鏈式方法解決。有時它有助於使界面更易於使用（即您提到的收集問題）。有時它不會。訣竅是弄清楚哪種情況適用。

Answer 7

鏈式方法和繼承存在一個共同的問題。假設您有一個C類，其方法F1（），F2（）等返回C.當您從C派生類D時，您希望方法F1，F2等現在返回一個D，以便D的可鏈式方法可以被稱爲鏈中的任何地方。