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

以下列方式将比较器应用于列表时，使用的设计模式是什么，或者这里使用的技术是什么？

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

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

});

---

解决方案

TL；dr：

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

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

---

以下列方式将比较器应用于列表时，使用的设计模式是什么，或者这里使用的技术是什么？

由于此问题已标记为OOP，因此这里本身没有使用OOP设计模式。这是普通的多态。有些程序员可能称之为策略模式，但我不同意。Strategy模式提倡组合而不是继承，其中您使用的是has-a关系，而不是is-a关系。

一些程序员可能会进一步争辩说，我们正在将排序Strategy传递给Collections.sort方法，因此这就是策略模式；但是，需要承认的是，Strategy是策略模式的组件之一。Strategy模式的另一个重要组件是其Context，它与Strategy建立Has-A关系。此组件是策略模式背后动机的核心，即优先选择组合而不是继承。你不能把整体中的一部分去掉，而把分离出来的部分称为整体。您不能将Context从策略模式中去掉，而将其余部分称为策略模式。

Collections.sort是一个static方法，它允许您以多态方式替身Comparator要在运行时使用的实现。

---

支持材料

让我们看看GoF中的策略模式的定义：

将算法封装在对象中是该策略的目的 (315)模式。模式中的关键参与者是战略 对象(它们封装了不同的算法)和 由他们操作。合成器是策略；它们封装了不同的格式化算法。合成是排序器策略的上下文。

.

对象组合提供了一个潜在的更可行、更灵活的扩展机制。

现在应该很清楚，多态和策略模式之间存在细微差别。Strategy模式讨论使用组合的上下文，如上面粗体中突出显示的那样。Collections类未与比较器建立组成关系。此外，Strategy模式的class diagram显示了一个称为上下文的组件，它构成了Strategy界面。

这个问题被标记为OOP，但是如果我们想要谈论当涉及到函数式编程范例时Collections.sort代表什么模式，我会说它代表函数式编程。(如果必须将函数传递给方法和OOP模式，我会说它非常(不完全)类似于命令模式，而不是策略模式)

相关内容：Does Functional Programming Replace GoF Design Patterns?