不使用工厂模式时，策略模式中switch语句应置于何处？

首先给你吃个定心丸：你把switch放在Service类的Calculate方法里的实现，完全符合策略模式的设计初衷，而且是不使用工厂模式时的合理选择。

为什么这个位置没问题？ #

策略模式的核心目标是将算法（策略）的定义与使用算法的上下文解耦，让策略可以独立于业务逻辑变化。它并没有禁止存在“策略选择逻辑”——只是要求这个选择逻辑不要和上下文的核心业务逻辑（比如这里的计算执行）耦合在一起。

看你的代码结构：

• CalculateClientContext是纯粹的上下文类，它只负责接收一个策略实例，然后调用策略的方法完成计算。它完全不知道具体是加法还是减法，也不需要关心——这完美实现了策略与上下文的分离。
• Service类的Calculate方法则专门负责策略的选择与注入：根据传入的Operation枚举，创建对应的具体策略对象，再把它交给上下文去执行。这里的switch只做一件事：匹配枚举并创建策略，没有和计算逻辑混在一起，保持了清晰的关注点分离。

和工厂模式的区别 #

你提到“见过带switch的方法返回策略实例属于工厂模式”——没错，那是简单工厂的典型写法，但这和你的实现并不冲突：

• 如果把策略创建逻辑抽成一个独立的类/方法（比如MathOperationFactory.Create(operation)），那就是工厂模式；但如果你的策略选择逻辑只在这一个地方用到，不需要复用，完全可以像你这样直接写在服务方法里。这依然是策略模式的合理实现，并没有违反任何设计原则。

后续扩展的建议 #

如果之后需要新增乘法、除法等运算，你只需要：

1. 新增实现IMathOperation的MultiplyOperation、DivideOperation类；
2. 在Service.Calculate的switch里新增对应的case。

这个过程中，你完全不需要修改CalculateClientContext的代码——这符合开闭原则（对扩展开放，对修改关闭），这也是策略模式的核心优势之一。

如果后续发现这个策略选择逻辑需要在多个地方复用，再把它抽成独立的工厂类也不迟，这是一种渐进式的、符合实际业务迭代的设计方式。

总结 #

设计模式是解决问题的工具，不是刻板的规则。你的实现清晰分离了策略定义、上下文执行和策略选择三个部分，完全满足策略模式的核心要求，switch的位置非常合理。

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