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

DR：

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

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

When applying a comparator to a list in the following manner, what is the design pattern being used or what is the technique being used here?

因为这个问题被标记为OOP，所以这里本身没有使用OOP设计模式。这是一个简单而古老的多态现象。有些程序员可能称之为策略模式，但我不同意。策略模式提倡组合而不是继承，即使用有关系而不是有关系。

有些程序员可能会进一步争辩说，我们正在将排序Strategy传递给Collections.sort方法，所以这就是策略模式；但是，我们需要承认的是，Strategy是策略模式的一个组成部分。战略模式的另一个重要组成部分是它的Context，它与战略建立起了密切的关系。这个组件是策略模式背后的动机的核心，策略模式更喜欢组合而不是继承。你不能从整体中取一部分，而仍然称之为分离的部分为整体。你不能把Context从策略模式中去掉，而仍然把其余的部分称为策略模式。

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

支撑材料

让我们看一下GoF中战略模式的定义：

Encapsulating an algorithm in an object is the intent of the Strategy
( 315) pattern. The key participants in the pattern are Strategy
objects (which encapsulate different algorithms) and the context in
which they operate. Compositors are strategies; they encapsulate different formatting algorithms. A composition is the context for a compositor strategy.

....

Object composition offers a potentially more workable and flexible extension mechanism..

现在应该清楚的是，多态性和策略模式之间存在细微的区别。战略模式讨论了使用上面粗体突出显示的组合的上下文。Collections类不与比较器建立成分关系。此外，策略模式的类图显示了一个名为上下文的组件，该组件构成了策略接口。

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

相关内容：函数式编程是否取代了GOF设计模式？

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

我认为最好先看另一种形式的

collections.sort(我收集)

它没有任何算法可以在运行时比较项目。在这种方法中，它使用由项目继承提供的算法(通过实现可比较的接口)。不是以一种直截了当的方式，但如果我们看这个有点灵活，这就是模板模式。此方法使用继承，并且项的行为在运行时不能更改。

但第二种形式

collections.sort(mycollection，比较算法)

我们在运行时发送行为，这与模板模式(继承)不同，当我们使用运行时提供的和可更改的行为时，这是可能的。这是战略模式中最重要的部分。

有人可能会问，战略模式的组成部分在哪里？组合并不仅仅是为了保存算法以便在需要时使用它。但在这种情况下，只要需要算法，它就会作为参数传递，因为collections类是一个utils类，用于不同的目的，而不是我们在策略模式的原始版本中看到的上下文类。