※ 引述《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