前言：
做项目的时候经常会这样的体会：我的代码实现需求了，代码重用性也可以。由于前期需求分析不彻底，只考虑到一种情况，做出来的东西给用户测试的时候，发现又需要改动，这个时候又会觉得前期的设计太过复杂，改动也比较麻烦。当然问题的根本原因是需求分析不彻底，或者对业务敏感度不够。面向对象的封装特性的核心是封装变化点，由于没有察觉到业务变化点，也就无法封装变化点。基于这个问题，我总结的方法是（1）多考虑用户的潜在需求 （2）无法感知用户潜在需求的情况下，代码设计尽量简单，不要做过多设计和封装，在重构的时候再做代码结构设计。当然这是题外话，下面是项目开发中一个小的需求场景。
需求描叙：
现在项目有一个银行卡对账的功能，主要是从银行那边拿到银行卡对账单（不同银行对账单格式不一样），需要跟系统的刷卡数据进行对账，需要对账的关键字段是已知的。已知一个项目只会有一个银行账单类型，我们希望实施的时候只需要修改配置即可实现当前业务。
需求分析与设计：
对账主要做两个工作（1）读取对账文件，并导入数据 （2）做对账操作。根据面向对象设计原则：封装变化点。在这个业务中，银行对账单格式会不一样，不同的格式的对账文件需要转成目标格式。就是需要对"格式转换"这个操作进行抽象。这里想到策略模式，策略模式就是对算法的抽象。下面是策略模式UML图：
接下来是处理对于策略的选择我们需要做到可配置，就是创建对象的时候能做到类似于Ioc容器那样动态配置。由于当前系统没有用到ioc容器，所以引入ioc容器有点杀鸡用牛刀的味道，用反射工厂就能解决这个问题，反射工厂模式我就不多说了。
关联模式比较：
在这里顺便比较一下策略模式跟代理模式（下面图片是网上找的）：
相同点：
（1）都有另外一个对象的引用（从字面意义上说，都有代理的意味，其实就是有一个组合关系）
区别：
（1）代理类和实现类做的是同样的事情，需要实现相同的接口。
（2）策略模式的重点是对算法封装，左边是一个管理类，管理类的类似一个适配器，实现对接口的转换（当然左边不是重点）。
上面是个人理解，如果有理解不到位的，欢迎拍砖！！！