有关足球的场景策略模式分享
你了解策略模式么？如果你对足球很熟悉，那么看了下面的介绍后，你大概会同样熟悉电磁阀策略模式了。
这里设计了一个有关足球的场景，在进攻当中暂分为传球和射门两个动作。
最开始你可能会这样想，设计一个电磁阀抽象类(Attact)，传球和射门分别定义好，子类会有一些他们个性的东西。比如球员号码，教练名称等等。
后来你发现传球和射门可能会分好多种，传球可分为短传和长传，射门又分为巴蒂式射门和因扎吉式的抢点。这样就不能将他们都写在这个抽象类 (Attact)中，比如有的队员就是一个工兵型的（像AC米兰的加图索）他不停的抢断传球，很少参与到射门当中来。这样再定义若干个子类来继承 (Attact)就不能满足需求。
我们可以把诸如传球和射门等动作抽象出来。组合到该抽象类中，只需在其中调用电磁阀具体的方法即可。
像这样来定义：（其中Passable和Shootable为行为接口）
- package strategy;
- /**
- * @author edison
- * @date 2009-9-24
- */
- public abstract class Attact {
- Passable pass;
- Shootable shoot;
- public abstract void display();
- public void ownPass(){
- pass.action();
- }
- public void ownShoot(){
- shoot.action();
- }
- public void setPass(Passable pass) {
- this.pass = pass;
- }
- public void setShoot(Shootable shoot) {
- this.shoot = shoot;
- }
- }
这里我们采用了策略模式，将传球和射门这一类动作定义为标准，封装起来，让他们之间可以互相的组合和替换，这样有效的使具体操作和实现分离。
上面一段话也可以这样说：
策略模式定义了算法族，分别封装起来，让它们之间可以互相替换电磁阀，此模式让算法的变化独立于使用算法的气动隔膜泵客户。
得到几个设计原则：
1.找到应用中可能变化之处，把它们独立初以来，不要和那些不需要变化的代码混在一起。
2.针对接口编程，而不是针对实现编程。
3.多用组合，少用继承。
类图：
以上就是策略模式的一个简单案例。
