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 design-pattern。这是一个普通的旧多态。一些程序员可能将其称为策略模式，但我不同意。 Strategy 模式提倡 Composition 而不是 Inheritiance，您使用 has-a 关系而不是 is -a 关系。

一些程序员可能会进一步争辩说，我们将排序Strategy 传递给Collections.sort 方法，所以这是策略模式；然而，需要承认的是Strategy 是策略模式的组成部分之一。 Strategy 模式的另一个重要组成部分是它的Context，它与Strategy 建立HAS-A 关系。这个组件是 Strategy Pattern 背后动机的核心，它更喜欢 composition 而不是 inheritance。你不能从整体中取出一个部分，仍然把那个分离的部分称为一个整体。您不能将Context 从策略模式 中取出，而仍将其余部分称为策略模式。

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

---

支持材料

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

将算法封装在对象中是 Strategy 的意图 (315) 模式。该模式的主要参与者是策略 对象（封装了不同的算法）和上下文 他们经营的。合成器是策略；它们封装了不同的格式化算法。 合成是合成策略的上下文。

....

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

现在应该清楚多态和策略模式之间存在细微差别。 Strategy 模式讨论了一个使用 composition 的 Context，如上面 bold 中突出显示的那样。 Collections 类没有与 Comparator 建立 composition 关系。此外，Strategy Pattern 的 class diagram 显示了一个名为 Context 的组件，它构成了 Strategy 接口。

这个问题被标记为OOP，但是如果我们想讨论Collections.sort 在函数式编程范式中代表什么模式，我会说它代表函数式编程。 （如果我必须将函数传递给方法等同于 OOP 模式，我会说它更接近（不完全）类似于 Command 模式 而不是 Strategy 模式）

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

Answer 2

我认为先看看另一种形式会更好

Collections.sort(myCollection)

在运行时没有任何算法来比较项目。在这种方法中，它使用由 Items 继承提供的算法（通过实现 Comparable 接口）。不是直截了当，但如果我们稍微灵活一点，这就是模板模式。这种方法使用继承并且项目的行为不能在运行时改变。

但在第二种形式

Collections.sort(myCollection, 比较算法)

与模板模式（继承）不同，我们在运行时发送行为，当我们使用运行时提供的可变行为时，这是可能的。这是策略模式中最重要的部分。

可能有人会问Strategy Pattern的Composition部分在哪里？组合不仅仅是为了保存算法，以便在需要时使用它。但是在这种情况下，每当需要算法时，它都会作为参数传递，因为 Collections 类是用于不同目的的 Utils 类，而不是我们在原始版本的策略模式中看到的 Context 类。

Answer 3

Collections.sort() 使用Strategy 模式。