為什么Collections類包含獨立的（靜態）方法，而不是將其添加到List接口？

Question

對於Collection中所有以List為第一個參數的方法，為什么這些方法不只是List接口的一部分？

我的直覺是：給定一個List對象，該對象本身應“知道”如何對其自身執行諸如rotate（），shuffle（）或reverse（）之類的操作。 但是，相反，作為一名Java程序員，我必須檢查List接口中的方法以及Collections類中“在那兒”的靜態方法，以確保使用的是規范的解決方案。

為什么將某些方法作為靜態獨立方法放置在Collections類中，而不是添加到List接口中（並因此由某些現有的或可能的基類實現）？

我試圖更好地理解Java集合框架背后的設計決策。

在這里，我是否忽略了一些令人信服的OO設計原則？ 還是僅出於某些實際的性能原因而進行了這種區分？

Answer 1

關鍵是給定適當的原始操作（刪除，設置等），可以執行一次更多的高級操作（排序，隨機播放，二進制搜索） ，而不是通過每個列表實現來實現。

實際上，java.util.Collections類似於.NET的Enumerable類-充滿了通用方法，這些方法可以在任何集合上工作，以便它們可以共享一個實現並避免重復。

Answer 2

列表界面方法背后的理性

1. List接口是Java運行時的核心部分，在推出自己的List實現時，要完全實現所有成員已經有些麻煩了。 因此，添加與列表的定義不直接相關的其他方法有點多余。 如果在List實現上需要這些方法，為什么不對接口進行子類化然后再要求它們呢？
2. 如果您打算在1.3版中說出來，並通過添加新的實用程序方法將功能添加到List接口，則將破壞該接口的所有以前的實現者。
3. 從域驅動設計的角度來看，集合中的實用程序方法不屬於列表的普通域。
4. 關於OO設計原則，我認為區分應用程序OO設計和語言運行時OO設計非常重要。

Java的作者可能對API的多年使用產生了事后的看法和看法，因此他們的做事可能大不相同。 也就是說，C＃IList接口與Java的接口非常相似，並且C＃的作者確實具有這種觀點。

Answer 3

在某種程度上，這肯定是一個判斷電話。 我認為要考慮的主要折衷是：在向接口添加方法時，該接口的每個實現者都必須編寫代碼來實現它。

如果該方法的語義足以使接口的不同實現以不同的方式最好地實現這些語義，那么最好將其放在接口中。 （當然，如果不能簡單地根據接口中的其他方法來定義語義，那么它必須是接口中自己的方法。）

另一方面，如果語義可以根據接口中的其他方法進行定義，並且接口的實現者往往會一遍又一遍地編寫相同的代碼，那么最好使用一種實用方法它以接口的實例作為參數。

Answer 4

它們是實用程序方法，而不是List的核心功能。 如果您添加了對List可能執行的所有操作，則List接口只會變得腫。 並且Collections中的操作不需要了解List的內部，它們在公共接口上操作，因此可以很高興地生活在外部類中。

Answer 5

這里有兩種解釋：

1. 歷史記錄：Collections類是在List接口之后創建的。 設計人員選擇保留現有接口的向后兼容性。 否則，許多開發人員將不得不更改其代碼。

2. 邏輯上：您正在談論的方法不需要有關List實現的內部知識，並且可以在實現它的任何collection上實現。