189 8069 5689

“HeadFirst设计模式“:策略模式

策略模式

成都创新互联公司主要从事成都网站建设、网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务龙湾,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108

问题的描述:

需求:开发一个鸭子游戏,能游泳,有外观,实现类图如下:

“Head First 设计模式“ :策略模式“Head First 设计模式“ :策略模式

增加的需求:

1. 加入飞行功能

2. 加入呱呱叫的功能。。。等等,暂时的解决方式如下:

“Head First 设计模式“ :策略模式“Head First 设计模式“ :策略模式

上线后出现了些问题:

1. 所有的鸭子都能叫吗?木头鸭子呢?

2. 所有的鸭子都能飞吗?木头鸭子呢?橡皮鸭子呢?


总结下,使用继承的缺点:

  1. 代码在多个子类中重复

  2. 运行时的行为不容易改变

  3. 很难知道鸭子的全部行为

  4. 改变会牵一发动全身,造成其他鸭子不想要的改变

  5. 。。。

好吧,我们引入接口来进一步修改,类图如下:

“Head First 设计模式“ :策略模式“Head First 设计模式“ :策略模式

问题已经解决了,但是鸭子子类有40多种,我们修改fly方法,难道修改40种样本?以后的维护的坑有点大哦!


总结下,这种方式的缺点:

  1. 代码在多个子类中重复

  2. 维护成本提高(有40个子鸭子类,要修改fly方法需要改40次?)

  3. 。。。

问题不断,我们用设模式来解决这个问题,先看看定义:策略模式:定义算法族,分别封装起来,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。

好,我们修改下,类图如下:

“Head First 设计模式“ :策略模式“Head First 设计模式“ :策略模式

我们用这个模式解决了:

1. 鸭子行为的各种各样性(子类行为和超类没有直接的关系了,添加删除行为不影响继承体系)

2. 代码重用,维护问题(子类太多时修改行为特别麻烦,代码重复,只修改算算法组就搞定)

3. 动态修改行为(Setter和Getter方法来灵活配置行为)

4. 。。。

这章我们学到的设计原则:

设计原则1: 封装变化(找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起)。

设计原则2: 针对接口编程,而不是针对实现类

设计原则3: 多用组合,少用继承



分享标题:“HeadFirst设计模式“:策略模式
标题来源:http://cdxtjz.cn/article/poshph.html

其他资讯