/**
* @author: takumiCX
* @create: 2018-10-13
**/
public abstract class Car implements Move{
//汽车品牌
private String brand;
public Car(String brand) {
this.brand = brand;
}
}
这样所有继承Car的具体汽车类都必须实现自己的move方法,也就是让具体的汽车子类来决定汽车的具体行为:到底是使用汽油运行还是使用电池运行。但是这么做至少有以下几个缺点
1.具体的汽车运行行为不方便后期维护。因而move行为无法被复用,具体的实现都分散在了子类中。如果要对某种驱动方式的实现进行修改,不得不修改所有子类,这简直是灾难。
2.导致类数量的膨胀。同样品牌的汽车,由于有汽油和电动两种运行方式,不得不为其维护两个类,如果在增加一种驱动方式,比如氢能源驱动,那不得为每个品牌的汽车再增加一个类。
3.不方便move行为的扩展,也不方便动态的更换其实现方式。
3.2.2 if-else的实现方式move方法接受客户端传递的参数,通过if-else或者swich-case进行判断,选择正确的驱动方式。
public void move(String moveStrategy) {
if("electricity".equals(moveStrategy)){
System.out.println(" Use Electricity Move!");
}else if("gasoline".equals(moveStrategy)){
System.out.println(" Use Gasoline Move!");
}
}
但这样做相当于硬编码,不符合开闭原则。比如我要增加一种氢能源的驱动方式,这种实现就需要修改move中的代码。而如果使用上面说的策略模式,则只需要增加一个实现实现策略接口的具体策略实现类,而不需要修改move中的任何代码,即可被客户端所使用。
/**
* @author: takumiCX
* @create: 2018-10-15
**/
public class HydrogenMovetrategy implements MoveStrategy {
@Override
public void move() {
System.out.println(" Use Hydrogen Move!");
}
}
1.可以优化类结构,当类的某种功能有多种实现时,可以在类中定义策略接口,将真正的功能实现委托给具体的策略实现类。这样避免了类膨胀,也能更好的进行扩展和维护。
2.避免使用多重条件判断导致的硬编码和扩展性差的问题
3.可以使具体的算法实现自由切换,增强程序设计的弹性。
4. 使用工厂方法模式改进原有策略模式所有的策略实现都需要对外暴露,上层模块必须知道具体的策略实现类,这与迪米特法则相违背。为此,可以使用工厂方法模式进行解耦。
策略工厂接口
/**
* @author: takumiCX
* @create: 2018-10-16
**/
public interface MoveStrategyFactory {
MoveStrategy create();
}
氢能源驱动方式的工厂
/**
* @author: takumiCX
* @create: 2018-10-16
**/
public class HydrogenMoveStrategyFactory implements MoveStrategyFactory {
@Override
public MoveStrategy create() {
return new HydrogenMovetrategy();
}
}
客户端
/**
* @author: takumiCX
* @create: 2018-10-13
**/
public class Client {
public static void main(String[] args) throws IllegalAccessException, InstantiationException, ClassNotFoundException {
TeslaCar car = new TeslaCar("Tesla");
MoveStrategyFactory factory = new HydrogenMoveStrategyFactory();
MoveStrategy moveStrategy = factory.create();
car.setMoveStrategy(moveStrategy);
car.move();
}
}