Collections.sort使用什么设计模式？
以下列方式将比较器应用于列表时，使用的设计模式是什么或此处使用的技术是什么？
Collections.sort(myCollection, new Comparator() { @Override public int compare(MyItem item1, MyItem item2) { return item1.getId().compareTo(item2.getId()); } }); TL; DR ：
Collections.sort是一个简单多态替换的示例，无论您是使用函数编程还是面向对象编程来进行此替换。 术语策略模式不能与多态或function编程互换。
我们仍然可以说我们正在将排序Strategy传递给sort方法但没有Context ，它不是策略模式的同义词。
以下列方式将比较器应用于列表时，使用的设计模式是什么或此处使用的技术是什么？
由于此问题已被标记为OOP ，因此此处没有使用OOP 设计模式 。 这是普通的老式多态性 。 一些程序员可能称之为战略模式，但我不同意。 策略模式提倡使用has-a关系而不是is-a关系的Composition over Inheritiance 。
一些程序员可能会进一步争辩说我们正在将一个排序Strategy传递给Collections.sort方法，所以这就是策略模式 ; 但是，需要承认的是Strategy是战略模式的组成部分之一。 战略模式的另一个重要组成部分是其与战略建立HAS-A关系的Context 。 这个组件是战略模式背后的动机的核心，即优先考虑组合而不是inheritance 。 你不能从整体中脱颖而出，仍然把这个分开的部分称为整体。 您不能将Context从策略模式中删除，并仍将其余部分称为策略模式 。
Collections.sort是一个static方法，允许您多变量替换Comparator实现以在运行时使用。
支持材料
让我们来看看GoF对战略模式的定义：
将算法封装在对象中是策略（315）模式的目的。 模式中的关键参与者是策略对象（它封装了不同的算法） 以及它们运行的上下文 。 合成者是战略; 它们封装了不同的格式化算法。 合成是合成器策略的上下文 。
….
对象组合提供了一种可行的更可行和灵活的扩展机制。
现在应该清楚， 多态性和战略模式之间存在细微差别。 策略模式讨论了使用上面以粗体突出显示的合成的上下文 。 Collections类不与Comparator建立组合关系。 此外， 策略模式的类图显示了一个名为Context的组件，它构成了Strategy接口。
这个问题被标记为OOP但是如果我们想谈谈Collections.sort在函数式编程范例中所代表的模式，我会说它代表函数式编程。 （如果我不得不将一个函数传递给一个方法到一个OOP模式，我会说它紧密（不完全）类似于Command模式而不是策略模式 ）
相关内容 ： function编程是否取代了GoF设计模式？
Collections.sort（）使用策略模式。
我认为最好先看另一种forms的
Collections.sort（myCollection）将
哪个没有得到任何算法来比较运行时的项目。 在这种方法中，它使用由项的inheritance提供的算法（通过实现Comparable接口）。 不是直截了当的方式，但如果我们看一点灵活，这就是模板模式 。 此方法使用inheritance和项目的行为在运行时不能更改。
但在第二种forms
Collections.sort（myCollection，比较算法）
我们在运行时发送不同于模板模式（inheritance）的行为，这在我们使用运行时提供的和可更改的行为时是可能的。 这是战略模式中最重要的部分。
有人可能会问这里的战略模式的构成部分在哪里？ 组合不仅仅是保持算法，以便在需要时使用它。 但是在这种情况下，每当需要算法时，它都作为参数传递，因为Collections类是一个Utils类，用于不同的目的，而不是我们在Strategy Pattern的原始版本中看到的Context类。