项目背景
由于学校现在推行信息化管理，响应党的号召，于是我校体育部要求建立系统来管理日常的工作，于是交给了校内的一个创业团队，项目经理小王同学就开始分析、调研系统的模型。经过一段时间的规划，他构建出了两个个对象，一个是篮球队，一个是足球队。为了保证代码的复用性，它抽象出了队伍这个父类，其中包含两个事件，一个训练，一个比赛。
代码实现
/**
* 抽象父类
* @project Test
* @date 2018年4月24日 上午11:19:52
* @author Huaxu-Charles
*/
public abstract class Team {
/**
* 训练
*/
public void train() {
System.out.println("队伍训练中。。。。");
}
/**
* 比赛
*/
public void game() {
System.out.println("队伍比赛中。。。。");
}
public abstract void display();
}
public class FootballTeam extends Team{
@Override
public void display() {
System.out.println("======足球队======");
}
}
public class BasketballTeam extends Team{
@Override
public void display() {
System.out.println("======篮球队======");
}
}
//测试方法
public static void main(String[] args) {
BasketballTeam baskTeam = new BasketballTeam();
FootballTeam footTeam= new FootballTeam();
baskTeam.display();
baskTeam.game();
baskTeam.train();
footTeam.display();
footTeam.game();
footTeam.train();
}
}
#运行结果 ======篮球队====== 队伍比赛中。。。。 队伍训练中。。。。 ======足球队====== 队伍比赛中。。。。 队伍训练中。。。。
经过努力之后小王同学的设计完成了老师的需求。子类篮球和足球如果不满意父类定义的“训练”还可以重写父类的方法，这里就不进行演示了，调用方法是一样的。
新需求
过了一段时间之后，老师发现足球队的训练强度不够，于是在训练之后添加了晚课的教学，这个时候小王同学开始思考系统功能的添加。然后他采用的OO（面向对象设计）思维的继承方式的解决方法是
oo原则解决新需求
public abstract class Team {
........
/**
* 晚课
*/
public void evensong() {
System.out.println("队伍晚课中。。。。");
}
public abstract void display();
}
但是问题来了，不是所有的队伍都需要上晚课的，这里上晚课的只有足球队，如果在父类添加这事不科学的。这里就引申出了继承的问题：对类的局部改动，尤其超类的局部改动，会影响其他部分。影响会有溢出效应
oo原则解决新需求的不足
public class FootballTeam extends Team{
@Override
public void display() {
System.out.println("======足球队======");
}
/**
* 晚课
*/
public void evensong() {
System.out.println("队伍晚课中。。。。");
}
}
这里子类添加父类不存在功能，也就是要求的晚课，但是如果这样的话，需要添加晚课的如果是5支队伍，那么你就需要在这个5个队伍的类中都去写这五个一样的方法，代码重用率低。而且这个时候如果在添加一个新的需求：队伍添加了一个教师助训队，帮助校队日常训练，但是不参与比赛？思考一下这个时候又怎么去做那？超类挖的一个坑，每个子类都要来填，增加工作量，复杂度O(N^2)。不是好的设计方式
用策略模式来新需求解决
需要新的设计方法，应对项目的扩展性，降低复杂度：分析项目中变化与不变化部分，提取变化部分，抽象成接口+实现；分析哪些功能是根据新需求变化的？
项目重构
/**
* 比赛族接口
*/
public interface Game {
public void game();
}
public class CommonGame implements Game{
@Override
public void game() {
System.out.println("队伍比赛中。。。。");
}
}
public class ProvinceGame implements Game{
@Override
public void game() {
System.out.println("队伍正在省赛中。。。。");
}
}
/**
* 训练族接口
*/
public interface Train {
public void train();
}
public class CommonTrain implements Train{
@Override
public void train() {
System.out.println("队伍训练中。。。。");
}
}
public class MorningTrain implements Train{
@Override
public void train() {
System.out.println("队伍正在早训中");
}
}
public class TeacherTrain implements Train{
@Override
public void train() {
System.out.println("教师正在助训中。。。");
}
}
/**
* 理论课族接口
*/
public interface SClass {
public void classing();
}
public class EveningClass implements SClass{
@Override
public void classing() {
System.out.println("队伍正在晚课。。。。");
}
}
/**
* 校队抽象父类
*/
public abstract class Team {
Game game;
Train train;
SClass sclass;
/**
* 训练
*/
public void train() {
train.train();
}
/**
* 比赛
*/
public void game() {
game.game();
}
/**
* 上课
*/
public void eveningClass() {
sclass.classing();
}
public void setGame(Game game) {
this.game = game;
}
public void setTrain(Train train) {
this.train = train;
}
public abstract void display();
}
/**
* 篮球队
*/
public class BasketballTeam extends Team{
public BasketballTeam() {
game = new CommonGame();
train = new CommonTrain();
}
@Override
public void display() {
System.out.println("======篮球队======");
}
}
/**
* 足球队
*/
public class FootballTeam extends Team{
public FootballTeam() {
game = new CommonGame();
train = new MorningTrain();
sclass = new EveningClass();
}
@Override
public void display() {
System.out.println("======足球队======");
}
}
/**
* 教师助训队
*/
public class TeacherTeam extends Team{
public TeacherTeam() {
train = new TeacherTrain();
}
@Override
public void display() {
System.out.println("======教师助训队======");
}
} 经过这样的定义，每个校队在进行初始化构建的时候只需要new出对应需要选择的族的实现类即可。而且这里还添加了set方法程序还可以在后期就行重新添加。
public static void main(String[] args) {
Team baskTeam = new BasketballTeam();
Team footTeam = new FootballTeam();
Team teacherTeam = new TeacherTeam();
baskTeam.display();
baskTeam.game();
baskTeam.train();
footTeam.display();
footTeam.game();
footTeam.train();
footTeam.eveningClass();
teacherTeam.display();
teacherTeam.train();
// 改变篮球为省赛
baskTeam.display();
baskTeam.setGame(new ProvinceGame());
baskTeam.game();
}
// 运行结果 ======篮球队====== 队伍比赛中。。。。 队伍训练中。。。。 ======足球队====== 队伍比赛中。。。。 队伍正在早训中 队伍正在晚课。。。。 ======教师助训队====== 教师正在助训中。。。 ======篮球队====== 队伍正在省赛中。。。。
最后就引出了策略模式的概念：分别封装行为接口，实现算法族，超类里放行为接口对象，在子类里具体设 定行为对象。原则就是：分离变化部分，封装接口，基于接口编程各种功能。此模式让行为 算法的变化独立于算法的使用者。
策略模式结构
| 封装类 | 也叫上下文，对策略进行二次封装，目的是避免高层模块对策略的直接调用。 |
| 抽象策略 | 通常情况下为一个接口，当各个实现类中存在着重复的逻辑时，则使用抽象类来封装这部分公共的代码，此时，策略模式看上去更像是模版方法模式。 |
| 具体策略 |
具体策略角色通常由一组封装了算法的类来担任，这些类之间可以根据需要自由替换。
|
策略模式优缺点
优点：
- 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
- 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
- 避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，使用多重条件判断是非常不容易维护的。
缺点：
- 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。
- 必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，是不是先要明白这三种算法的适用情况？再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，客户端是不是也要明白链表和数组有什么区别？就这一点来说是有悖于迪米特法则（后期介绍）的。
使用场景
策略模式它实质上就是面向对象中的继承和多态，至少在以下两种情况下，大家可以考虑使用策略模式，
- 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
- 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
策略模式是一种简单常用的模式，在进行开发的时候，会经常有意无意地使用它，一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。