终于可以静下心来学习一些有用的理论了。

今天学习第一章：策略模式。

怎么说呢？这一章讲的主要是设计思想的引入以及思考。比方说面向接口的编程而不是面向实现的编程，还有把变化与不变化的部份分离，把变化的部份封装。

我们先从经常用的设计习惯说起。比方说Person类，第个Person都会打电话，然，每个不同类的Person又会使用不同的电话打。我经常是这样设计的，在Person类里定义callByPhone抽象方法，然后让子类继承，不同的子类代表着不同类的Person，子类实现callByPhone方法，一般就是这样去做。

然，上面的方法就是一种面向实现编程，因为每一个Person子类的实现都绑定在了具体的子类上了，哪怕这些实现算法有重复，也因为绑定在了具体的子类上而变得无法重用而冗余。

在这个例子中，不变化的地方是Person类除callByPhone之类的行为，而变化的则是callByPhone，而callByPhone的方式很可能会重用和变化，所以这时callByPhone这样的行为本身就是一个实体对象，应该对其进行封装，以便以后重用。我们定义CallByPhoneBehavior接口，让具体的打电话实现实现这个接口，然后再把这个行为赋给具体的Person类，这样就达到了重用。

这就是微略模式，把变化的可重用的部份分别封装起来，让它们之间可以互相替换，这个模式让具体的算法变化独立于使用这些部份的用户，以达到灵活性。

呃……描述的不怎么的，大脑里有一个很好的潜意识图。这次公司的平板电脑保密检查项目，其中有一系列项是这样的，要针对不同的Excel文档模板生成文档、合并文档、提取摘要。

流程都是一样的，生成文档、合并文档、提取摘要。不同的是，不同的文档模板在生成文档、合并文档、提取摘要时所读到的Excel单元格坐标的定义不同，所以算法也不一定相同。而我是这样设计的，所有的流程都一样，把这些可变动不同的部份设计成接口，实现不同的类，这样，每一个文档模板一来，我就要简单的实现一个这个接口的类就行，然后配置一下。

不知觉中，自己使用了策略模式。呵……

同样的，在最近的Android项目中，我也用到了策略模式，在底层负责数据读取的部份，因为在网络接口未定期时，可以定义底层数据读取部份的接口，实现一个模拟数据实现类，使得上层使用到它的类一直以为是从网络取得数据，这样就可以很舒服地进行上层的功能开发了。等接口一来，立即替换成真实的网络接口实现，再一测试，也就没什么大问题了。

因为中文水平是小学水平，所以只能写个大概，看不懂的客官不要拍砖。