Collections.sort使用什么设计模式？

Question

以下列方式将比较器应用于列表时,使用的设计模式是什么或此处使用的技术是什么？

Collections.sort(myCollection, new Comparator<MyItem>() {

    @Override
    public int compare(MyItem item1, MyItem item2) {
        return item1.getId().compareTo(item2.getId());
    }

});

Answer 1

TL; DR:

Collections.sort是一个简单的多态替换的示例,无论您是使用函数编程还是面向对象编程来进行此替换.术语策略模式不能与多态或功能编程互换.

我们仍然可以说我们正在将排序传递Strategy给sort方法,但没有它Context,它不是策略模式的同义词.

以下列方式将比较器应用于列表时,使用的设计模式是什么或此处使用的技术是什么？

由于此问题已被标记为OOP,因此此处没有使用OOP 设计模式.这是普通的老式多态性.一些程序员可能称之为策略模式,但我不同意.该战略格局主张构成了Inheritiance在您使用一个具有-A的关系,而不是is-a的关系.

一些程序员可能会进一步争辩说我们正在Strategy对Collections.sort方法进行排序,因此这就是策略模式 ; 但是,需要承认的是战略模式Strategy的组成部分之一.所述的另一重要组分策略图案是其即建立HAS-A与关系策略.这个组件对于战略模式背后的动机至关重要,即优先考虑构成而不是继承.你不能从整体中脱颖而出,仍然把整个分开的部分称为.你不能脱离战略模式,仍然将其余部分称为战略模式.ContextContext

Collections.sort是一种static允许您以多态方式替换Comparator在运行时使用的实现的方法.

支持材料

让我们来看看定义策略模式从GoF的:

将算法封装在对象中是策略(315)模式的目的.模式中的关键参与者是策略对象(它封装了不同的算法)以及它们运行的​​上下文.合成者是战略; 它们封装了不同的格式化算法.合成是合成策略的上下文.

....

对象组合提供了一种可行的更可行和灵活的扩展机制.

现在应该清楚,多态与战略模式之间存在细微差别.该策略图案关于说话上下文使用的组合物如在高亮粗体上方.本Collections类不建立一个组成与关系比较.此外,类图的策略模式示出了被称为组件上下文用来构成策略接口.

这个问题被标记为OOP,但是如果我们想谈谈Collections.sort在函数式编程范例中代表什么样的模式,我会说它代表函数式编程.(如果我不得不将一个函数传递给一个方法到一个OOP模式,我会说它紧密(不完全)类似于命令模式而不是策略模式)

相关内容:功能编程是否取代了GoF设计模式？

Answer 2

Collections.sort() 使用策略模式。