当以下列方式将比较器应用于列表时，正在使用什么设计模式或此处使用什么技术？
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传递给Collections.sort方法，所以这就是策略模式;然而，需要承认的是，Strategy是策略模式的组成部分之一。《战略》模式的另一个重要组成部分是其与《战略》建立HAS-A关系的Context。这个组成部分是战略模式背后的动机的核心，即更喜欢组合而不是继承。你不能从整体中取出一部分，但仍然称该分离的部分为整体。您不能将Context从策略模式中取出，而仍然将其余部分称为策略模式。
Collections.sort是一种static方法，允许您以多态方式替换要在运行时使用的Comparator实现。
支持材料
让我们来看看GoF对策略模式的定义：
将算法封装在对象中是策略的意图 (315)模式。该模式的主要参与者是战略 对象(封装不同的算法)和上下文 他们经营的。合成器是策略;它们封装了不同的格式化算法。合成是合成器策略的上下文。
....
对象组合提供了一种可能更可行和更灵活的扩展机制。
现在应该很清楚，多态性和策略模式之间存在微妙的区别。策略模式讨论使用上面粗体突出显示的构图的上下文。Collections类不与比较器建立组合关系。此外，策略模式的类图显示了一个名为上下文的组件，它组成了策略接口。
这个问题被标记为OOP，但如果我们想讨论当涉及到函数式编程范式时Collections.sort代表什么模式，我会说它代表函数式编程。(如果我必须将函数传递给方法等同于 OOP 模式，我会说它非常(不完全)类似于命令模式而不是策略模式)
相关内容： 函数式编程会取代GoF设计模式吗？
Collections.sort() 使用策略模式。
我认为最好先看看另一种形式的
Collections.sort(myCollection)
这不会获得任何算法来在运行时比较项目。在这种方法中，它使用由项目继承提供的算法(通过实现可比较接口)。不是以直截了当的方式，但如果我们稍微灵活一点，这就是模板模式。此方法使用继承和行为的项不能在运行时更改。
但在第二种形式
Collections.sort(myCollection， comparing-algorithm)
我们在运行时发送行为，这与模板模式(继承)不同，当我们使用运行时提供和可更改的行为时，模板模式是可能的。这是策略模式中最重要的部分。
有人可能会问，策略模式的组成部分在哪里？组合不仅仅是为了保存算法，以便在需要时使用它。但在这种情况下，每当需要算法时，它都会作为参数传递，因为集合类是一个用于不同目的的 Utils 类，而不是我们在策略模式的原始版本中看到的上下文类。