有关足球的场景策略模式分享
你了解策略模式么?如果你对足球很熟悉,那么看了下面的介绍后,你大概会同样熟悉电磁阀策略模式了。
这里设计了一个有关足球的场景,在进攻当中暂分为传球和射门两个动作。
最开始你可能会这样想,设计一个电磁阀抽象类(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.多用组合,少用继承。
类图:
以上就是策略模式的一个简单案例。