策略模式

在開發中，有時候實現一個功能有多種方法或者說是策略，在實現的過程當中能夠根據條件來進行選擇不一樣的方法或者策略，好比對一個集合進行排序，能夠根據客戶端傳進來的條件來選擇不一樣的排序算法，如冒泡排序，堆排序，快速排序......等。

對於這種需求，通常的解決辦法就是在一個方法中 經過 if....else if....else 或者 switch case 來解決，這樣有一點很差的地方，若是咱們要添加一個新的算法，或者刪除一個已有的算法，則必需要修改源代碼來實現，去掉/添加一個 else 分支或者 case分支，代碼的擴展性和維護性較差，對於這種需求的話，可使用策略模式來進行解決。

策略模式  ：

定義一系列的算法,把每個算法封裝起來, 而且使它們可相互替換。

下面以一個網購付款方式爲例進行說明：

在網購付款的時候，能夠選擇的付款方式有不少種，如支付寶，微信，信用卡和 ApplePay等。

首先定義抽象策略類PayWay：

public abstract class PayWay {
	
	public abstract boolean pay(double money);
	
}

定義具體策略類：

支付寶支付類：

/**
 * 支付寶支付
 * @author Administrator
 *
 */
public class AlPay extends PayWay{

	@Override
	public boolean pay(double money) {
		System.out.println(String.format("使用支付寶成功付款：%f", money));
		return true;
	}
}

微信支付類：

/**
 * 微信支付
 * @author Administrator
 *
 */
public class WeChatPay extends PayWay{

	@Override
	public boolean pay(double money) {
		System.out.println(String.format("使用微信成功付款：%f", money));
		return true;
	}
}

信用卡支付類：

/**
 * 信用卡支付
 * @author Administrator
 *
 */
public class CreditCardPay extends PayWay{

	@Override
	public boolean pay(double money) {
		System.out.println(String.format("使用信用卡成功付款：%f", money));
		return true;
	}
}

客戶端類

在客戶端類中，只需持有抽象策略類的一個引用。

class Client{
	private PayWay payWay = null;
	
	public void setPayWay(PayWay payWay) {
		this.payWay = payWay;
	}
	
	public void pay(double money){
		payWay.pay(money);
	}
}

測試：

public static void main(String[] args) {
		Client client = new Client();
		// 支付寶
		client.setPayWay(new AlPay());
		client.pay(1000);
		
		//微信
		client.setPayWay(new WeChatPay());
		client.pay(1000);
		
		//信用卡
		client.setPayWay(new CreditCardPay());
		client.pay(1000);
	}

結果：

使用支付寶成功付款：1000.000000
使用微信成功付款：1000.000000
使用信用卡成功付款：1000.000000

如今若是想添加一種新的付款方式，ApplePay，只需新加一個類，繼承抽象策略類便可，

ApplePay類：

/**
 * ApplePay支付
 * @author Administrator
 *
 */
public class ApplePay extends PayWay{

	@Override
	public boolean pay(double money) {
		System.out.println(String.format("使用蘋果成功付款：%f", money));
		return true;
	}
}

能夠看到，新添加一個策略或者算法，對原來的代碼沒有改動，只是新加了一個類而已，若是想不使用某個算法或策略，如不想使用信用卡支付，則在客戶端進行調用的時候，不傳入 CreditCardPay對象便可，對原來的代碼也沒有改動，由此能夠看到維護性和擴展性較高。

缺點：

策略模式也有它的缺點，如客戶端在進行調用的時候，必須知道每一個算法或者策略的不一樣；若是策略不少，則會有不少的具體策略類，形成大量的類。