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