深入浅出设计模式(Design Pattern)----策略模式(Strategy Pattern)
这是设计模式开篇,我觉得策略模式真的对我来说是一种醍醐灌顶的感觉.让我感觉:哇,真的诶,用这种设计模式真的可以方便很多,代码的层次结构更清晰.下面就让我们开始吧.策略模式:策略模式定义了算法族,分别将其封装起来,让他们之间可以相互转换,这个模式使得算法的变化独立于使用算法的客体. 但是严谨的定义通常是难以理解的,接下来我们通过一个故事,来深刻理解这种设计模式的使用场景和强大之处吧(以下例子来自Head First Design Pattern 但是我会用自己的语言诠释一遍,并加上自己的理解).
前面三张图的子类搞错了(有一个子类应该是Man);
1.先从简单的模拟人物的应用开始
假如小明的公司开发一个应用来根据用户的要求来生成各种模拟人物(奇迹暖暖?).用户填写参数然后就可以生成各种人物形象.这个系统使用了标准的OO技术,设计了一个Human超类(Superclass),然后让不同的人物来继承这个超类.
看起来没什么难的?是吧.
2.现在我们得让人跑起来
公司现在发现,做这种类型应用的人太多了,光是让用户可以看到外表(display())这件事太简单,很多应用都可以,所有决定让人物可以跑起来更加立体的展示人物,这样子就可以吸引更多用户了.
小明于是拍脑袋一想,这还不简单吗?我只需要在超类Human里面加上一个run()方法,让所有的人物都可以跑起来.
可是第二天leader就打电话给小明了,狠狠地骂了小明一遍,原来应用中新加了一个角色,这个角色是一个跛脚的人,由于继承了run()方法,现在这个跛脚的人物也在画面中跑来跑去.这种简单的逻辑错误让公司丢了大脸.所以说要谨慎使用继承
3小明想到进行第一步改正—覆盖
于是小明将LameHuman(跛脚的人)类中的run()覆盖掉,变成什么也不做.那么这个跛脚的人就不能跑了.
方法看起来不错,可是下次如果加一个ParalyzedHuman(瘫痪的人)那不仅得把run()方法覆盖,还得把walk()方法覆盖,这什么时候是个头啊?小明看起来很懊恼.
4.小明又有了新点子—使用接口好像是个不错的选择.
这样好像就解决了这样的问题,可以leader看看了看小明说:“后期有很多类都能walk(),而且walk()的方式几乎没有什么区别,假如有20个类都能walk(),而且walk()的方式没有区别,那你想想你要把20个类的Walkable都实现,而且都是重复的代码,能不能用用脑子?”.现在小明陷入了麻烦,你能想到一个方法来帮助他吗?
5.解决方案— 将应用中可能需要变化的地方独立出来
我们可以利用多态来实现不同人物的walk();我们在超类中加入一个属性(WalkBehavior),然后在通过不同的子类来实现不同的walk(),这样既可以减少重复的代码,也为代码提供了足够的灵活程度.