《Head First设计模式》读书笔记 -- （第一章）策略模式

 本文属贫僧不吃肉原创，欢迎转载，转载请注明来自 http://never-say-never.iteye.com/blog/851923

  

在开始之前，先熟悉一下OO设计的一些原则。

 

OO设计原则之一：封装变化

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

 

OO设计原则之二：多用组合，少用继承

组合（composition）和继承不同的地方在于，对象的行为不是通过继承来的，而是和适当的行为对象（算法族）“组合”来的。

 

OO设计原则之三：面向接口编程

针对接口编程而不是针对实现编程。

 

所以，得到了如下的定义。

策略模式：（把变化之处抽象出来）定义算法族，分别封装，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。                                              --《Head first设计模式》

 

 

 

 

先来一个抽象女子类，女子有一个动作show()，每位女子的动作都会不同，比如貂蝉喜欢看月亮，马诺喜欢抽鞭子，浮云妹子喜欢看世博，小泉彩喜欢拍爱情教育片等等。

 

正是因为每朵女子的“动作”不同，如果使用继承Lady类的方式来构造子类的话，那就得给每个子类重写父类的show()。

 

为了更好的实现代码复用，因此我们请出策略模式

 

public abstract class Lady{
Behavior behavior ; 

public void setBehavior(b){
this.behavior=b;
}

public void show(){
behavior.show();
}
public void smile(){
System.out.println(“刷牙，姐一直用舒肤佳！”)
}
}

 

 

 

 其实，把凤姐定义成一个类，似乎不太妥当，应该是个对象。但是把它想成“像凤姐的那一类人”就合理多了~~哈哈，开个玩笑，我是懒得返回去改了，将就看一下吧~

 

public class FengJie extends Lady{
//定义凤姐类
	public FengJie(){
		behavior=new Merry();
	}

 

 

 

 

 

 

public class FuRong extends Lady{
//定义芙蓉姐姐类
public FuRong(){
		behavior=new Dance();
	}
}

 

 

 

 

 

 

 

 

 

根据OO设计原则，我们抽象出了“变化”的部分 — 女子的动作 ，因为每个女子的动作都不一样

 

public interface Behavior{
	public void show();
}

 

 

//定义结婚类
public class Merry implements Behavior{
public void show(){
System.out.println(“人家只嫁给氢化烟酒僧~”);
}
}

 

//定义芙蓉姐姐的跳舞类~~
public class Dance implements Behavior{
public void show(){
System.out.println(“姐不是巴黎欧莱雅，你不值得拥有”);
}
}

 

 

好了，写个测试类，来测试一下

 

public class Test{
public static void main(String[] args) {
         Lady fj =  new FengJie(); //凤姐
         lady fr =  new FuRong();  //芙蓉姐姐
         fj.show();             //小凤，秀一下
	fj.smile();            //小凤，笑一个
         fr.show();             //芙蓉姐姐，秀一下
	fr.smile();            //芙蓉姐姐，笑一个
	}
}

 

 

 

 

  所以，通过抽象“变化”的部分，分离开固定的和活动的，然后，面向接口。

 

前面说的好像有点水，如果看懂了，你很强。如果没看懂，没关系，下面我们再换个角度思考一下策略模式。

 

简单，就好比魔兽，英雄是父类，子类有剑圣、圣骑，每个子英雄拥有的技能是不同的，但是总的技能就那么几十种，只是每个英雄取的技能组合不同而已。

如果把几十种技能全写进父类里，那子英雄继承的时候就把需要的和不需要的技能都全部继承过去了。

如果把父类拥有技能写成虚函数，那又要给每一个英雄实现拥有技能函数。

...

而用策略模式怎么解决这个问题的呢：

1.找出变化的部分：技能，再把它声明成一个总的抽象技能接口

2.给每个子技能接口一个实现，如：医疗波，战争践踏等

3.把英雄和其具备的技能组合（composition）到一起，如牛头和战争践踏、冲击波等组合。

//OO思想：多用组合，少用继承

 

这样，在保证每个英雄都具有不同技能的同时，也最大地实现了代码的重用。因为，每个技能只用实现一次就可以了。

 

 

 

分享一些小弟在网上或书上看到的短句，仔细品味后发现，觉得很有用，努力ing~。

 

1.良好的OO设计必须具备可复用、可扩充、可维护三个特性

2.模式不是代码，而是针对设计问题的通用解决方案。

3.模式不是被发明，而是被发现的。

4.我们常把系统中会变化的部分抽出来封装。

5.模式让开发人员之间有共享的语言，能够最大化沟通的价值。

 

 

 

 

附上策略模式的一个很好的实现例子给大家交流学习~~