函数式编程（非纯）中策略模式实现是否遗漏设计核心？

嘿，这个问题问得很精准！咱们先把策略模式的核心要点拎出来，再对照你的实现一一拆解。

首先，策略模式的核心本质是把可变的行为封装成独立的“策略”，让上下文（也就是使用这些策略的主体）可以在运行时动态切换行为，同时让策略和上下文解耦。它的核心要素通常有三个：

• 抽象策略：定义所有策略必须遵守的契约（比如参数格式、返回值要求），保证上下文能统一调用不同策略
• 具体策略：实现抽象策略的具体逻辑（比如你的Zip、Rar压缩）
• 上下文：持有策略的引用，提供切换策略的方法，并把具体执行逻辑委托给策略

接下来看你的实现：

1. 上下文（FileCompressor）：你做的很到位——有strategy变量存储当前策略，setCompressionAlgo方法用来动态切换策略，compressFiles方法把压缩逻辑委托给strategy执行，完全符合上下文的职责。
2. 具体策略（ZipCompressor、RarCompressor）：两个压缩函数各自实现了具体的压缩逻辑，是合格的具体策略。
3. 默认策略（noOp）：设置默认的空操作策略，避免空引用问题，这个细节考虑得很周全！

那有没有遗漏核心概念？有一个小但重要的点：缺少抽象策略的约束契约。

在你的实现里，strategy可以被赋值为任何函数，但没有明确规定所有压缩策略必须遵循的规则——比如必须接受filesList作为唯一参数，必须完成压缩相关逻辑。如果有人不小心写了一个签名不匹配的策略（比如不需要参数、或者参数是单个文件而不是列表），赋值给strategy后，调用compressFiles时肯定会出问题。

举个改进的例子，你可以先定义一个抽象策略的“模板”，明确契约：

// 抽象策略契约：所有压缩策略必须接受filesList参数
compressionStrategy:{[filesList] /* 定义参数要求，可留空作为契约标记 */}

然后让zipCompress和rarCompress都严格遵循这个签名实现，这样就能保证上下文调用策略时不会出现参数不匹配的问题，也让新加入的策略有明确的实现标准。

总结一下：你的实现已经抓住了策略模式最核心的动态切换+委托执行思想，唯一的小遗漏就是没有明确的抽象策略契约，补上这个约束后，就完全符合策略模式的核心设计概念了！

内容的提问来源于stack exchange，提问作者nyi