挑战：不同场景下的函数参数差异
在软件开发中，我们经常会遇到这样的场景：某个操作的核心逻辑在不同条件下需要不同的输入参数。例如，在一个招聘系统中，验证面试官的函数validaterecruiters可能根据面试类型（如技术面试或hr面试）而需要不同的参数。
考虑以下初始代码结构，它尝试使用一个查找表recruitersCategoryHandlers来根据面试类别动态获取并调用验证函数：
import { getHrRecruiters, getRecruiters } from '../queue';
import { validateTechnicalInterview } from './validateTechnicalInterview';
import { matchHrRecruiters } from './matchHrRecruiters';
import { THrInterviewer, THrRecruit, TRecruit } from '../../types';
export const recruitersCategoryHandlers = {
TECHNICAL_INTERVIEW: {
getter: getRecruiters,
setter: {
validateRecruiters: (
recruiters: THrInterviewer[],
recruit: TRecruit | THrRecruit
) => validateTechnicalInterview(recruiters, recruit),
},
},
HR_INTERVIEW: {
getter: getHrRecruiters,
setter: {
validateRecruiters: (
recruiters: THrInterviewer[],
recruit: TRecruit | THrRecruit,
param3: any, // 额外的参数
param4: any // 额外的参数
) => matchHrRecruiters(recruiters, recruit as THrRecruit, param3, param4),
},
},
};
// 尝试调用，但参数不确定
const matchedSlots = getMatchingSlots(
recruitersCategoryHandlers[
interviewCategory as EInterviewCategory
].setter.validateRecruiters(???), // 此处参数如何统一传递？
slotsWithEmail
);如上所示，TECHNICAL_INTERVIEW的validateRecruiters只需要两个参数，而HR_INTERVIEW的则需要四个参数。直接在调用点统一传递参数会变得非常棘手，因为不同分支所需的参数数量和类型不一致，导致调用逻辑混乱且难以维护。
解决方案：策略设计模式
为了解决这种参数差异性带来的调用困境，我们可以采用策略设计模式（Strategy Design Pattern）。策略模式定义了一系列算法，将每一个算法封装起来，并使它们可以相互替换。这意味着，我们可以在运行时选择不同的算法，而客户端代码无需了解具体算法的实现细节。
在这个场景中，不同的validateRecruiters实现就是不同的“策略”。
1. 定义策略接口
首先，我们定义一个通用的接口（在TypeScript中是interface），它声明了所有具体策略必须实现的方法。为了适应不同数量的参数，我们可以使用剩余参数（rest parameters）...params: any[]。
// 定义策略接口
interface ValidateRecruitersStrategy {
validateRecruiters(recruiters: THrInterviewer[], recruit: TRecruit | THrRecruit, ...params: any[]): any;
}这个接口确保了所有具体策略都将拥有一个名为validateRecruiters的方法，并且能够接受一组基础参数以及任意数量的额外参数。
2. 实现具体策略
接下来，为每种面试类型创建具体的策略类，它们都将实现ValidateRecruitersStrategy接口。
技术面试策略：
// 实现技术面试策略
class TechnicalInterviewStrategy implements ValidateRecruitersStrategy {
validateRecruiters(recruiters: THrInterviewer[], recruit: TRecruit | THrRecruit): any {
// 技术面试只使用前两个参数
return validateTechnicalInterview(recruiters, recruit);
}
}HR面试策略：
// 实现HR面试策略
class HrInterviewStrategy implements ValidateRecruitersStrategy {
validateRecruiters(recruiters: THrInterviewer[], recruit: TRecruit | THrRecruit, ...params: any[]): any {
// HR面试需要额外的参数，从params中解构或按顺序获取
const [param3, param4] = params;
return matchHrRecruiters(recruiters, recruit as THrRecruit, param3, param4);
}
}通过这种方式，每个策略类内部负责处理其特有的参数需求，而外部调用者无需关心这些细节。
3. 集成策略到查找表
现在，我们可以更新recruitersCategoryHandlers对象，使其setter属性存储相应策略类的实例，而不是直接的函数字面量。
// recruitersCategoryHandlers 使用策略模式进行定义
export const recruitersCategoryHandlers = {
TECHNICAL_INTERVIEW: {
getter: getRecruiters,
setter: new TechnicalInterviewStrategy(), // 存储策略实例
},
HR_INTERVIEW: {
getter: getHrRecruiters,
setter: new HrInterviewStrategy(), // 存储策略实例
},
};4. 统一调用验证函数
通过策略模式，现在无论面试类型如何，我们都可以使用统一的方式来调用validateRecruiters方法。调用者只需根据当前上下文提供所有可能需要的参数，具体的策略实例会自行决定使用哪些参数。
// 假设已确定面试类别及其他所需参数
const interviewCategory = 'HR_INTERVIEW'; // 或 'TECHNICAL_INTERVIEW'
const param3 = 'someValueForParam3'; // 针对HR_INTERVIEW的额外参数
const param4 = 'anotherValueForParam4'; // 针对HR_INTERVIEW的额外参数
const slotsWithEmail = {}; // 示例值，实际应为具体数据
// 获取面试官数据（getter）
const recruiters = recruitersCategoryHandlers[interviewCategory].getter();
// 统一调用 validateRecruiters
// 注意：这里将所有可能的参数都传递了过去
const validatedResult = recruitersCategoryHandlers[interviewCategory].setter.validateRecruiters(
recruiters,
slotsWithEmail, // 对应 recruit 参数
param3, // 对应 param3
param4 // 对应 param4
);
// 最终的匹配槽位
const matchedSlots = getMatchingSlots(validatedResult, slotsWithEmail);
console.log('Matched Slots:', matchedSlots);在这个调用示例中，即使TECHNICAL_INTERVIEW策略不需要param3和param4，传递它们也不会导致错误，因为TechnicalInterviewStrategy的validateRecruiters方法签名只声明了它需要的参数，并不会使用多余的参数。而HrInterviewStrategy则会正确地接收并使用这些额外的参数。
优势与注意事项
优势：
- 灵活性与可扩展性： 添加新的面试类型（例如FINAL_INTERVIEW）时，只需创建新的策略类并将其添加到recruitersCategoryHandlers中，无需修改现有代码。
- 代码解耦： 具体的验证逻辑被封装在独立的策略类中，客户端代码（调用validateRecruiters的部分）与具体实现解耦。
- 提高可读性与可维护性： 职责分离，每个策略类只关注自己的验证逻辑，代码结构更清晰。
- 消除条件语句： 避免在调用点出现大量的if/else或switch语句来判断参数传递方式。
注意事项：
- 参数管理： 尽管策略模式允许统一调用，但调用者仍需负责收集所有可能需要的参数。如果参数集非常庞大且差异显著，这可能会导致调用点的参数列表过长。
-
类型安全： 在TypeScript中使用...params: any[]虽然灵活，但会牺牲一定的类型安全。在实际项目中，可以考虑以下策略来提高类型安全：
- 如果参数差异不大，可以尝试使用联合类型或可选参数。
- 如果参数结构复杂，可以考虑将额外参数封装成一个单独的配置对象传递。
- 为每个具体策略定义更严格的参数类型，并在策略内部进行类型断言或校验。
- 策略选择： 确定使用哪个策略的逻辑（例如interviewCategory的判断）仍然存在于客户端代码中，但它仅仅是选择策略实例，而非实现具体逻辑。
总结
通过引入策略设计模式，我们成功地解决了在JavaScript中调用参数签名不同的函数这一常见挑战。这种模式不仅使得代码结构更加清晰、易于维护和扩展，而且提供了一种优雅的方式来管理复杂多变的业务逻辑。在面对需要根据不同上下文执行相似但参数不同的操作时，策略模式无疑是一个值得优先考虑的强大工具。
