重构，设计模式，封装

1 ：设计原理：

   1面向借口编程，2：开闭原则   3：组合编程

   设计模式：

  1： 单列模式 参考http://iluoxuan.iteye.com/blog/2031206

  2：工厂模式，创建对象  spring中beanfactory --一路的继承接口

  3：模板方法， 抽象类定义方法模板，然后抽象一个方法延迟到子类实现

  4：策略模式： 策略接口，有不通的具体策略实现

  5：适配器模式， 有extends，和组合两种适配，还可以结合模板方法

  6：代理模式： 静态代理（就一组合）， JDK动态代理，CGLIB动态代理

  7：责任链模式:   Fileter接口引用本身，相当于一个链表，然后一个管理类注册相关具体类 也可以用来重构if else等

  8：观察者模式： 那事件说： 一个Listener接口，具体监听实现，一个Event接口，一个发布类

可以用来发布相关事件，注册监听

  9： 回调模式，java中传入infterface接口实现一个方法，回调模式；长见在spring data框架中

非常有利于实现不通的业务逻辑 不确定的

 10:  builder模式，没什么好说的就一创建具体对象的部走，有一天提示下 builder模式可以方法发挥builder

非常符合流接口设计比如 stringbuilder sb，  sb.append().instert()这样、

   上面这些都是实际中写的比较多的，其他的没怎么用到 也没仔细研究

总这一句话，模式有时候并不怎么好，比如会增加很多类，具体的业务，具体的选择

 

做到很好的扩展是我们的目的

 

 

当我们熟悉了大部分模式，熟悉了抽象编程，和组合编程 

重构的时候我们必须往这些方面去思考，

 

比如我去重构一个商店的购买系统，有打折，每天限购次数， 限购周期，限购批次，等其他一些活动的时候

起初是 直接if else直接判断的

代码很少，看起来也不错，但是有个非常严重的问题每次有新的东西的时候 就要加一个if

过滤不显示的商品也得加一个if

 

很难修改，所以考虑用了过滤器，拦截器

由于使用了spring框架，而且具体的活动处理本身没有理由需要足够的优先级

 

有一个管理类spring管理 然后spring 注解管理具体的实现，那我们很简单的可以用注解活动所有的

具体处理的list

 

 可以参考：spring mvc中拦截器的实现，处理器适配的实现，spring中事件监听，