我越来越多地看到相同解决方案的新标签，但名称不同。在这种情况下，为什么我们不能简单地说 Execute Aroud 习语与 Strategy design pattern 相同？
当我阅读 Jon Skeet’s answer对于这个问题:“什么是‘Execute Around’成语？”，他说:
it's the pattern where you write a method to do things which are always required, e.g. resource allocation and clean-up, and make the caller pass in "what we want to do with the resource".
在这种情况下，@jon-skeet 使用 executeWithFile(String filename, InputStreamAction action) 方法作为该方法的示例，该方法执行始终需要的操作，并且接口(interface) InputStreamAction 作为我们想对资源做什么的抽象。
public interface InputStreamAction
{
void useStream(InputStream stream) throws IOException;
}
将此与 Stratey design pattern 进行比较为什么我们不能只说 InputStreamAction 接口(interface)定义了一系列算法？并且，InputStreamAction 接口(interface)的每个实现都对应于封装算法的具体策略。最后，这些算法是可以互换的，我们可以将 executeWithFile 与任何这些策略一起使用。
那么，为什么我不能解释 Jon Skeet’s answer作为 Stratey design pattern 的应用示例？
顺便问一下，哪个成语先出现？ Execute Around 还是 Strategy 设计模式？
虽然 Execute Around 惯用语通常与函数式编程有关，但我找到的关于它的唯一文档是在 Smalltalk Best Practice Patterns 中。 1997 年出版的 Smalltalk 编程语言范围内的书籍，它遵循 OO 方法。
因为设计模式描述了针对反复出现的问题的一般解决方案，所以我们可以说 Execute Around 和 Strategy 都是相同的解决方案解决不同的问题。所以，我问:我们真的需要一个不同的名称来标识相同的解决方案，当它应用于不同的问题时吗？
尽管我同意@iluwatar 的answer这是交流不同想法的方式，我仍然认为我可以传达 Execute Around 的想法，只是告诉它:“我使用策略来指定我想对资源做什么，它始终以相同的方式设置和清洁。”
所以 Execute Around 习语减少了歧义(这很好)，但同时增加了设计模式的名称？而且，这是一个好习惯吗？
最佳答案
在我看来，虽然两者可能是解决类似问题的方法，但它们是不同的成语，因此应该有不同的名称。
我称它们为成语，因为围绕它执行的只是一个 programming idiom ，用于许多典型情况(类似于所介绍的情况)，也用于多种语言。而且，至少据我所知，Execute Around 从未正式成为一种软件设计模式，至少现在是这样。
为什么它们不同？这是我的观点:
Stategy设计模式旨在(来自维基百科):
- defines a family of algorithms,
- encapsulates each algorithm, and
- makes the algorithms interchangeable within that family.
通常，策略 实例作为与上下文实例的长期关系，通常作为构造函数依赖项传递。即使上下文可能有策略的 setter ，相同的策略可以在对上下文的多次调用中使用，而调用者(客户端)甚至不知道该特定上下文正在使用哪个策略，并且此刻通话已完成。此外，相同的策略实例可能会在其公共(public)接口(interface)的多个方法中被上下文使用，而调用者甚至不知道其用法。
另一方面，execute around 习语 适用于参数化算法，其中调用者(客户端)应始终在每次调用中传递算法参数化函数。因此，传递的策略 函数只会影响该特定调用的行为，不会影响其他调用。
尽管所呈现的差异可能在理论上和修辞上存在缝合，但如果您将被调用的上下文置于多线程场景中，我认为差异会更加明显并且更容易被看到和“感觉到”。
如果没有大量的锁和同步，就不能在多线程场景中使用策略设计模式，至少在允许更改上下文策略的情况下是这样。如果不这样做，您会看到上下文和策略之间的关系会持续更长时间，因为它们通常存在于同一时间。
execute around 成语如果实现得当，应该不会患上这种“疾病”，至少如果传递的函数没有任何副作用的话。
总结一下，虽然Strategy 设计模式和execute around 习语可能接缝相似，可能用于解决类似的问题，并且可能接缝具有类似的静态结构，它们本质上是不同的，前者更面向对象风格，后者更实用，因此，它们应该有不同的名称!
我同意 Miguel Gamboa 的观点，大量使用具有相同含义的名称并不好，应该避免。但是，至少在我看来，情况并非如此。
希望这对您有所帮助!
关于java - 为什么 Execute Aroud 习语不被视为策略设计模式？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29166024/