当按以下方式将比较器应用于列表时，此处使用的设计模式是什么？使用的技术是什么？
Collections.sort(myCollection, new Comparator<MyItem>() { @Override public int compare(MyItem item1, MyItem item2) { return item1.getId().compareTo(item2.getId()); } });
TL; DR ：
Collections.sort是简单多态替换的示例，无论您使用 功能编程 还是 面向对象编程 进行此替换。术语 策略模式 不能与 多态性 或 函数编程 互换。
Collections.sort
仍然可以说我们正在将排序传递Strategy给该sort方法，但是如果没有Context，则它不是“ 策略模式”的 同义词。
Strategy
sort
Context
由于此问题已被标记为 OOP ，因此本来就没有使用 OOP 设计模式 。这是行动中常见的古老 多态性 。一些程序员可能将其称为“ 策略模式”， 但我不同意。该 战略 格局主张 构成 了 Inheritiance 在您使用一个 具有-A 的关系，而不是 is-a的 关系。
一些程序员可能会进一步辩称，我们正在Strategy对Collections.sort方法进行排序，因此这是 策略模式 ; 但是，需要承认的是这Strategy是“ 战略模式 ”的组成部分之一。所述的另一重要组分 策略 图案是其Context即建立 HAS-A 与关系 策略 。该组件是 策略模式 背后动机的核心， 策略模式 是优先考虑 组成而 不是 继承 。您不能从整体中分离出一部分，而仍将分离的部分称为整体。你不能Context走出 策略模式 并仍称为其余的 策略模式 。
Collections.sort是一种static方法，允许您 多态 替换Comparator要在运行时使用的实现。
static
Comparator
配套材料
让我们来看看定义 策略模式 从GoF的：
将算法封装在对象中是策略（315）模式的目的。模式的主要参与者是Strategy对象（封装了不同的算法） 和它们在其中运行的上下文 。合成者是策略；它们封装了不同的格式化算法。 合成是合成策略的背景 。 .... 对象组合 提供了一种可能更可行，更灵活的扩展机制。
将算法封装在对象中是策略（315）模式的目的。模式的主要参与者是Strategy对象（封装了不同的算法） 和它们在其中运行的上下文 。合成者是策略；它们封装了不同的格式化算法。 合成是合成策略的背景 。
....
对象组合 提供了一种可能更可行，更灵活的扩展机制。
现在应该很清楚， 多态 与 策略模式 之间存在细微的差异。该 策略 围绕图案会谈 上下文 使用 组合物 作为突出显示 粗体 上方。本Collections类不建立一个 组成 与关系 比较 。此外，类图的 策略模式 示出了组件调用的 上下文 ，其构成所述 策略 接口。
Collections
这个问题被标记为 OOP， 但是如果我们想谈谈Collections.sort功能编程范式代表什么模式，我会说它代表功能编程。（如果我必须将传递函数的方法等同于OOP模式，我会说它（而非完全）更像是 命令模式， 而不是 策略模式 ）
相关内容 ：函数式编程是否可以代替GoF设计模式？
