扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
策略模式
成都创新互联公司主要从事成都网站建设、网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务龙湾,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108
问题的描述：
需求：开发一个鸭子游戏，能游泳，有外观，实现类图如下：
增加的需求：
1. 加入飞行功能
2. 加入呱呱叫的功能。。。等等，暂时的解决方式如下：
上线后出现了些问题：
1. 所有的鸭子都能叫吗？木头鸭子呢？
2. 所有的鸭子都能飞吗？木头鸭子呢？橡皮鸭子呢？
总结下，使用继承的缺点：
代码在多个子类中重复
运行时的行为不容易改变
很难知道鸭子的全部行为
改变会牵一发动全身，造成其他鸭子不想要的改变
。。。
好吧，我们引入接口来进一步修改，类图如下：
问题已经解决了，但是鸭子子类有40多种，我们修改fly方法，难道修改40种样本？以后的维护的坑有点大哦！
总结下，这种方式的缺点：
代码在多个子类中重复
维护成本提高（有40个子鸭子类，要修改fly方法需要改40次？）
。。。
问题不断，我们用设模式来解决这个问题，先看看定义：策略模式：定义算法族，分别封装起来，它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
好，我们修改下，类图如下：
我们用这个模式解决了：
1. 鸭子行为的各种各样性（子类行为和超类没有直接的关系了，添加删除行为不影响继承体系）
2. 代码重用，维护问题（子类太多时修改行为特别麻烦，代码重复，只修改算算法组就搞定）
3. 动态修改行为（Setter和Getter方法来灵活配置行为）
4. 。。。
这章我们学到的设计原则：
设计原则1： 封装变化（找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起）。
设计原则2： 针对接口编程，而不是针对实现类
设计原则3： 多用组合，少用继承
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
微信二维码
移动版官网