策略模式（Strategy）

这里设计了一个有关足球的场景，在进攻当中暂分为传球和射门两个动作。

最开始你可能会这样想，设计一个抽象类(Attact)，传球和射门分别定义好，子类会有一些他们个性的东西。比如球员号码，教练名称等等。

后来你发现传球和射门可能会分好多种，传球可分为短传和长传，射门又分为巴蒂式射门和因扎吉式的抢点。这样就不能将他们都写在这个抽象类(Attact)中，比如有的队员就是一个工兵型的（像AC米兰的加图索）他不停的抢断传球，很少参与到射门当中来。这样再定义若干个子类来继承(Attact)就不能满足需求。

我们可以把诸如传球和射门等动作抽象出来。组合到该抽象类中，只需在其中调用具体的方法即可。

像这样来定义：（其中Passable和Shootable为行为接口）

Code
1 package strategy;
2
3 /**
4 * @author edison
5 * @date 2009-9-24
6 */
7 public abstract class Attact {
8 Passable pass;
9 Shootable shoot;
10
11 public abstract void display();
12
13 public void ownPass(){
14 pass.action();
15 }
16 public void ownShoot(){
17 shoot.action();
18 }
19
20 public void setPass(Passable pass) {
21 this.pass = pass;
22 }
23
24 public void setShoot(Shootable shoot) {
25 this.shoot = shoot;
26 }
27
28 }
29
这里我们采用了策略模式，将传球和射门这一类动作定义为标准，封装起来，让他们之间可以互相的组合和替换，这样有效的使具体操作和实现分离。

上面一段话也可以这样说：

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

得到几个设计原则：

1.找到应用中可能变化之处，把它们独立初以来，不要和那些不需要变化的代码混在一起。
2.针对接口编程，而不是针对实现编程。
3.多用组合，少用继承。