【HeadFirst设计模式】1.策略模式

##问题
假定你们公司要做一套模拟鸭子游戏:SimUDuck。游戏中会出现各种鸭子,一边游泳戏水,一边呱呱叫。

你想哈,这还不简单,我只要设计一个鸭子超类,并让各种鸭子继承此超类即可。呼哧呼哧,你撸起袖子就写下如下设计类图:

这里写图片描述

但有一天,你的leader心血来潮,觉得应该加点功能,应该加入会飞的鸭子。这时你想,这也不难,只需加个方法不就完了么。

这里写图片描述

这时就有问题了,橡皮鸭子(RubberDuck)居然满屏飞了。

显然这种设计的可扩展性非常差。

这时就涉及到OO设计中的一个重要原则——封装变化

找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起

我们发现fly和quack并不是所有鸭子的共性,故将它们抽离出来。
这里写图片描述这里写图片描述

设计两个接口:FlyBehavior, QuackBehavior。然后实现FlyWithWings和FlyNoWay两个类,一个表示会飞,一个不会飞。同理,我们实现三种代表三种不同叫的行为的类。

这时,考虑另一个重要的原则——多用组合,少用继承

这里写图片描述

这样设计有什么优势呢。显然,以后如果要增加新的行为,只要写一个新的行为类,并在Duck类里加一个对应的行为属性就可以了。这样,我们就把“行为”委托给一些类来处理。

这样,既保留了继承的复用性又拥有了可扩展性。

##总结
###设计原则

  • 封装变化
  • 多用组合,少用继承
  • 针对接口编程,不针对实现编程
    ###策略模式

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值