【设计模式】策略模式
1.UML
针对同一个算法/业务有不同的实现,在不同情况下使用不同的实现。
//定义算法接口 abstract class Strategy { public abstract void Algorithm(); } //封装算法实现1 class ConcreteStrategy1:Strategy { public override void Algorithm(){} } //封装算法实现2 class ConcreteStrategy2:Strategy { public override void Algorithm(){} } //封装算法实现3 class ConcreteStrategy3:Strategy { public override void Algorithm(){} } class Context { private Strategy st; //封装算法对象 public Context(Strategy _st) { st = _st; } public void DoAlgorithm() { st.Algorithm(); } }
Context ct = new Context(new ConcreteStrategy2()); //具体执行的算法由传入Context构造的类实例决定 ct.DoAlgorithm(); //算法的执行统一为DoAlgorithm()
和简单工厂的对比:
简单工厂,重点在将switch判断new不同具体类的过程封装。依赖所有具体类。客户端中获取实例。
策略模式,重点在将算法类/业务类的实例封装,通过方法调用,对外暴露一个统一的调用算法的接口,客户端通过调用这个接口调用算法,屏蔽调用不同算法时调用不同接口。
调用不同算法时,将不同的算法类的实例传入Context的构造函数。
2. 策略模式和简单工厂结合
策略模式,将决定使用什么算法的判断switch放在了客户端中,由客户端通过传入什么算法类的实例决定使用什么算法。增加了客户端和各种算法类的耦合,当增加算法实现时客户端的switch将会增加。
利用简单工厂的思想,将判断使用什么具体算法类的过程封装在Context类中。不再向Context的构造传入不同实例,而是传入switch的case,在构造中创建具体算法类的实例。
class Context { private Strategy st; //封装算法对象 public Context(string _case) { switch _case { case "1": st = new ConcreteStrategy1(); case "2": st = new ConcreteStrategy2(); case "3": st = new ConcreteStrategy3(); } } public void DoAlgorithm() { st.Algorithm(); } }
Context ct = new Context("2"); ct.DoAlgorithm(); //客户端使用算法还是使用统一的接口
好处:客户端彻底与具体的算法类解耦,连与抽象算法类Strategy都解耦了(Strategy对象封装在了Context中)。
但是,策略模式和简单工厂的结合,增加算法/业务实现时,还是要修改Context类。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 单元测试从入门到精通
· 上周热点回顾(3.3-3.9)