本文探讨了如何在JavaScript应用中，当函数调用需要根据不同上下文处理不同参数签名时，优雅地设计和实现解决方案。通过引入策略设计模式，我们将展示如何封装特定于上下文的逻辑，从而实现统一的函数调用接口，提升代码的可扩展性、可维护性和清晰度，尤其适用于处理面试官验证这类场景。
挑战：不同场景下的函数参数差异
在软件开发中，我们经常会遇到这样的场景：某个操作的核心逻辑在不同条件下需要不同的输入参数。例如，在一个招聘系统中，验证面试官的函数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中调用参数签名不同的函数这一常见挑战。这种模式不仅使得代码结构更加清晰、易于维护和扩展，而且提供了一种优雅的方式来管理复杂多变的业务逻辑。在面对需要根据不同上下文执行相似但参数不同的操作时，策略模式无疑是一个值得优先考虑的强大工具。
评论（已关闭）
评论已关闭