设计模式——策略模式

最近甚是无聊，研究下设计模式，以便在以后的开发中能够让自己的代码更加容易维护，降低耦合度。

设计模式之策略模式：

假如有这样的需求，让你做一个计算器，对商场购物人员进行价格计算，这时你会飞快地写下下面的代码：

public class calute{

//money为输入金额
double moneysum(double money){
return money;
}
}

一个公共的类，输入价格返回价格，这样一个简易的购物计算器就完成了。但是这时候经理说了，我想给不同的顾客分发会员卡，分金卡和银卡，金卡打五折，银卡打八折。

这时候你就想了这还不简单吗，我在这个类里在加上两个方法计算金牌卡的和银牌卡的会员不就可以了吗：

public class calute{

//money为输入金额
double moneysum(double money){
return money;
}

//money为输入金额
double moneysumJ(double money){
return money * 0.5;
}

//money为输入金额
double moneysumY(double money){
return money  * 0.8;
}

}

如果现在经历又说了，打完折后金牌返现10元，银牌返现8元，再加一个铜牌会员打九折，这时候你是不是有点烦，想打经理了。可是经理好像也没什么错误，改个需求对于程序员太常见了。那么就是不我们的代码写的不好咯。这时候善于发现的你就看出来了，上面的三个方法本质上其实是重复的。

现在我们利用策略模式来改写代码

public interface CaluateMoney {
//计算图书价格
public double Calute(double money);
}

//铜牌的

public class Apeople implements CaluateMoney{
//A购物不打折
@Override
public double Calute(double money) {
return money*0.9;
}
}

//银牌的

public class Bpeople implements CaluateMoney{
//B购物打八折
@Override
public double Calute(double money) {
return money*0.8;
}
}

//金牌的

public class Cpeople implements CaluateMoney{
//c购物5折
@Override
public double Calute(double money) {
return money*0.5;
}
}

//计算价格

public class Price {

protected Apeople apeople;
protected Bpeople bpeople;
protected Cpeople cpeople;
protected CaluateMoney caluateMoney;

public Price(CaluateMoney caluateMoney){
this.caluateMoney = caluateMoney;
}

protected double calute(double money){
return apeople.Calute(money);
}
}

这时候在客户端调用时，就是这样的：

Price price = new Price(new Apeople());
double caluteA = price.calute(100);

Price price2 = new Price(new Bpeople());
double caluteB = price2.calute(100);

Price price3 = new Price(new Cpeople());

double caluteC = price3.calute(100);

这时候是不是发现想算谁的算谁的，金牌银牌铜牌间都是进行调用计算方法但同时又是独立的。

总结起来：同一方法的不同实现。如果多个方法就写多个接口，就可以了。