Re: [問題] 語法（架構）的問題
※ 引述《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
推
03/08 08:19, , 1F
03/08 08:19, 1F
→
03/08 08:21, , 2F
03/08 08:21, 2F
→
03/08 08:33, , 3F
03/08 08:33, 3F
討論串 (同標題文章)