※ 引述《sbrhsieh (sbr)》之銘言： : ※ 引述《TonyQ (沉默是金)》之銘言： : : 這個問題的另一種問法應該是這樣的 , : : 為什麼是用 Collections 提供 sort method , : : 而不是由 AbstractCollection (List/Set 的父類別) 直接寫一個sort method. : : 這個問題在我的理解 , : : 其實是 util (算是外部擴充吧,不太會翻.) 跟 original 的差異 , : : 從原本的問題來看 , 這個問題可以從幾個方向下去著手 , : : 1. 繼承 AbstractCollection 的類別有規定一定需要排序嗎？ : : 基本上我們在探討的項目是當有 coder 試圖擴充類別時 , : : 是否需要進行這個項目 , 當然我們可以強迫性的要求 , : : 但是這樣做的結果往往只是讓寫子class變得又複雜又限制重重. : : 2. 如果有需要排序的情形 , 排序的行為是如何進行 : : 如果排序這個功能是依照各子類別而會有所不同的話 , : : 就可能會影響要實作的方式. : : 不過在這個例子中排序的行為不需要考慮 , : : 因為實際上是交給 Collection 中的成員實做 sortable 來作排序依據, : : 並且提供 Comparator 的方式來作排序行為擴充. : : 3. 目前的環境條件限制. : : 有時候基於向下相容以及環境條件的考量(像是用別人的lib等) , : : 我們會盡量避免修改(或甚至是無法修改) 現有的class定義 , : : 這時候我們也會傾向於撰寫 util class. : : 我並不曉得當初原始設計者的想法 , 不過 Collections 非常有 util的味道 , : 我認為當初不把 sort 列入 List(AbstractList) 規格的考量，主要是基於第一點。 : 泛 List 類一開始就設計成異質容器，一個容器內含不同種類的物件，element 與 : element 之間往往沒有順序(大小)上的意義，所以不應該把排序當作 List 類基本的 : 操作之一。 : 雖然可以選擇把 sort 當作是 List 的 optional operation(不支援此操作的 List : 可丟出 UnsupportedOperationException)。所幸不是，因為我個人不喜歡 interface : 裡有 optional operation 這樣子的設計。 interface 非常不適合定義 optional operation 若真的有 optional operation 還不如移動至另一個介面。 -------------- -------------- <<interface>> 改寫 <<interface>> List Sortable -------------- => -------------- sort() <---------optional operation sort() add(o: Object) -------------- -------------- -------------- <<interface>> List -------------- add(o: Object) -------------- 左圖為有 sort() 的 optional operation。可能有些實體類別支援此方法 但是有些實體類別不支援此方法，使用者難以信任此方法能不能排序串列 中的元素，造成系統模組的缺陷。 解決此種不信任的問題，可以改成右圖的結構。增加一個 Sortable 介面 若實體類別有實作 Sortable 則代表此類別可以排序串列內的元素，使用 者可以信任此方法確實有效果。 然而此例，排序演算法幾乎一模一樣，如果所有實作 Sortable 類別的 sort() 方法內的程式碼都相同，根本沒有必要讓所有類別分別實作一模一 樣的功能和實作細節，這樣只會使程式碼不斷地重複出現。 為了解決相同的排序法頻頻出現的問題，創建一個 Collections 的公用型 類別，將排序法放到這個類別，不要再讓類別們出現一模一樣的排序了。 如此一來，可以減少重複的程式碼，也減少相同實作的方法。您可以發現 List 的子類別中，add, remove 這幾種方法的實作細節不盡相同，然而排 序法卻是對於所有的類別都一模一樣！當然得放到特定的地方嚴加管理了！ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.116.247.13