初学设计模式（0）-----策略（虽被遗弃，确实万物起源，故谓之0）

曾经看到一位大牛说，学技术最好的方式之一，就是把学的东西写下来，而且还得写到通俗易懂，不仅仅只是一份技术文档或者一份读书笔记。于是，开通了自己的博客，写下这第一篇技术博客。

这几天过年在家，却是闲着略蛋疼，之前在一家外企和一个小创业公司呆了半年，技术磨练到没多少，却是认识到了很多开发中遇到的问题，尤其是后期维护，和面对不断改变的需求，作为一名实现设计的实践者而不是设计产品的思考者，“卧槽”的感叹想必是众多实践者的心声。就在这挣扎之时，“设计模式”如同九天玄女下凡，点播愚昧，救吾等于水火之中。于是，跟随娘娘，潜心修行，并记录下心得，以传众人。

心法（0）：策略。所谓，有勇无谋，匹夫一枚。coding讲究策略，面对变化无止尽的需求，不变应万变乃是至高心法，于是便有人提出，identify the aspects that vary and separate them from what stays the same.  这不过是句空话，却也引出了策略模式----定义一套算法，封装他们，让他们可互换，并且与client code隔离。废话不多说，上代码：

interface PayMoney{
	public void checkOut();//付钱
	public void getTicket();//拿发票
}
class PayMoneyWithCreditCard implements PayMoney{
	@override
	public void checkOut(){
		System.out.println("You pay the money by credit card");
	}
	@override
	public void getTicket(){
		System.out.println("You got the ticket and the discount");
	}
}
class PayMoneyWithCash implements PayMoney{
	@override
	public void checkOut(){
		System.out.println("You pay the money in cash");
	}
	@override
	public void getTicket(){
		System.out.println("You got the ticket and no discount");
	}
}
class CheckStand{
	public PayMoney payMoney;
	public void setPayMoney(PayMoney p){this.payMoney=p;
	public void getPaid(){
		this.payMoney.checkOut();
		this.getTicket();
	}
}

可见，收银台的付款方式并未创建两个首款方式，而是一个由一个PayMoney接口来设定。如此一来，在真正开始收款时，就不需要在client code中重写付款方式，直接创建对应的付款方式类，交由他来完成，即便日后需要增加某种付款方式，撤销某种付款方式，或者更改某种付款方式的细节，都不用在client code中重写代码。也许有人会问，client code是什么，他就是相当于我们常用的main函数内的代码，或者如同上方CheckStand中的getPaid()函数一样，如果不使用接口定义方式，那就必须得在getPaid()函数中重写付款逻辑，并且任何的需求改变，都要对这段代码重新更改，于是，便有了 What the hell!!!!!

当然，很多人都知道，策略现在很多人都不用了，理由？因为他真的不够用，单单凭着封装行为这等一级技能就干挑战终极boss么？想想一旦不同类型的行为一多，那岂不是有一大堆的成员变量要维护，client code中岂不是要创建一大堆的行为对象，一大堆的set代码，更何况，加入每个行为的具体实现细节牵涉到数据库，网络，本地文件读写，屏幕显示，错误提醒，那一个checkOut()一个getTicket()中要写多少的代码，一旦其中任何一个方面的需求做出了改变，我们又该如何快速定位到代码位置，还能保证代码的改变，不回影响其他的代码呢？

不用担心，当我们了解了策略，也就多了一层天赋，叫-----多态（堕胎？为啥qq输入法会直接显示这个。。。=.=），依赖接口，运行时得知对象类型。而这，正式设计原则中的另一条：program to an interface,not an implementation.既然有了多态这层天赋，dps已经有了质的飞跃。

那么，为了下一层天赋的开启，继续练级吧。