策略模式(Strategy Pattern)

本文通过鸭子游戏的例子,探讨了在软件设计中如何合理地使用继承与组合,避免因需求变更而导致的大规模代码修改。介绍了策略模式的概念,即将一组相关算法封装成独立的对象,以便在运行时自由切换。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

例子:

一个游戏中有各种鸭子,红头鸭,绿头鸭等等,很自然得出这样的设计:

这时,需求改变了(永远不变的是改变).游戏需要鸭子能飞起来, 在抽象的Duck类中加入一个方法fly(),是一个很自然的想法.

但是,问题出现了,一些不能飞的鸭子(比如橡皮鸭)也飞了起来.——继承带来的问题:牵一发而动全身

我们可以找到一个暂时的办法:覆盖橡皮鸭的fly()方法,使这个方法什么也不做。然而随着鸭子的数量的增加,你必须检查每一个不会飞,或者不会叫的的鸭子的方法都被覆盖掉了,这个工作量将是巨大的。

此时,另一种设计方式似乎可行:让某些鸭子“可以飞”,“可以叫”——即实现Flyable接口,如图:

这样设计似乎概念上非常清楚,但是带来的问题显而易见:

1) 由于接口中没有方法的实现,不能复用代码,导致许多类中都有大量重复的代码

2) 如果需要修改所有类的quack()方法,需要对大量(比如说48个)子类进行修改

那怎么样设计才好呢?先看一下下面的设计原则:

1. 找出应用中可能变化指出,把他们独立出来,不要和那些不需要变化的代码混在一起。——把会变化的部分取出来并封装,好让其他部分不受影响。 2. 针对抽象(接口)编程,而不是针对实现编程.

在该场景中,可能变化的是鸭子的行为:即鸭子游泳的行为,鸣叫的行为,不同的鸭子不一样。所以根据原则1我们需要将鸭子的行为独立出来,并且将其抽象,我们只针对鸭子行为的抽象编程。按照这个思路,得出设计:

显然,这样的设计克服了上面几种设计的缺点,它既有继承的优点:重用代码,又克服了它的缺点:不会牵一发动全身,修改一个鸭子的行为,不会影响其他鸭子。它甚至可以在运行时动态的改变鸭子的行为。因为它采用的是组合,而不是继承。

这里得到另一个设计原则

多用组合,少用继承。

至此,我们可以得出策略模式的定义了:

策略模式定义了算法簇,分别封装起来,让他们之间可以相互替换,此模式让算法的变化独立于使用算法的客户

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值