当按以下方式将比较器应用于列表时，所使用的设计模式是什么或这里使用的技术是什么？
Collections.sort(myCollection, new Comparator<MyItem>() {
@Override
public int compare(MyItem item1, MyItem item2) {
return item1.getId().compareTo(item2.getId());
}
});
TL;DR ：
Collections.sort是简单多态替换的一个示例，无论您使用函数式编程还是面向对象编程来进行此替换。术语策略模式不能与多态性或函数式编程互换。
我们仍然可以说我们正在将排序传递给该方法，但是如果没有 ，它不是策略模式的同义词。StrategysortContext
当按以下方式将比较器应用于列表时，所使用的设计模式是什么或这里使用的技术是什么？
由于这个问题已被标记为OOP，因此这里本身没有使用OOP设计模式。这是普通的老式多态性。一些程序员可能会称之为策略模式，但我不同意。策略模式提倡组合而不是继承，其中您使用有一个关系而不是一个是关系。
一些程序员可能会进一步争辩说，我们正在向方法传递排序，所以这就是策略模式;然而，人们需要承认的是，这是策略模式的组成部分之一。《战略》模式的另一个重要组成部分是它与《战略》建立HAS-A关系。这个组成部分是策略模式背后的动机的核心，即更喜欢组合而不是继承。你不能把一部分从整体中拿出来，然后仍然把分离的部分称为一个整体。您不能将策略模式取出，而仍将其余部分称为策略模式。StrategyCollections.sortStrategyContextContext
Collections.sort是一个允许您以多态方式替换要在运行时使用的实现的方法。staticComparator
支撑材料
让我们来看看GoF的策略模式的定义：
将算法封装在对象中是策略（315）模式的意图。模式中的关键参与者是Strategy对象（封装不同的算法）以及它们操作的上下文。合成器是策略;它们封装了不同的格式化算法。合成是合成器策略的上下文。
....
对象组合提供了一种可能更可行和更灵活的扩展机制。
现在应该清楚，多态性和策略模式之间存在细微差别。策略模式讨论的是使用上面以粗体突出显示的构图的上下文。该类不与比较器建立复合关系。此外，策略模式的类图显示了一个名为 Context 的组件，该组件组成了 Strategy 接口。Collections
这个问题被标记为OOP，但是如果我们想讨论当涉及到函数式编程范式时，模式会代表什么，我会说它代表函数式编程。（如果我必须将一个函数传递给一个方法等同于一个OOP模式，我会说它与命令模式非常接近（不完全）而不是策略模式Collections.sort)
相关内容： 函数式编程会取代 GoF 设计模式吗？
