Dive into Spring framework -- 了解基本原理（二）－－设计模式－part1

比较巧，本身在接触设计模式的时候，也刚开始学习spring，但惋惜的是，真的仅仅在学习“用”spring，天天都沉浸在会痛快的完成spring各类配置的快乐之中，但对成长无用。其实当初就清楚，spring框架中有大量设计模式，因而也下了代码来看，设计模式其实没那么简单，当初的学习也很皮毛，因此就没有发现spring中的金矿。如今动手，里面依然仍是金矿，但不要偷懒，让它彻底腐烂。［这是对本身的告诫］

开头上来就说到了spring跟设计模式，实际上，spring中的核心原则就是基于设计模式来构建的。这个时候继续祭出《敏捷软件开发》这本神书，结合里面比较全面的和具体的设计模式来大致讨论一下各类设计模式。（在此也建议将《敏捷》多看几遍，虽然里面用了c＋＋示例，但极易理解）

在学习和讨论每种设计模式以前，都应该明确这样几个问题：

1）这个模式是什么？

2）这个模式适应的场景是什么，有何限制？

3）《敏捷》里面是如何推出来用这个模式的？针对《敏捷》中的场景，如若不考虑这个模式，会如何出手？这种相似于范伟大师傅的神功，为什么降服不了“黑帮”？铁定被打趴在地上的缘由，有考虑过么？［范伟是俺的偶像］

Command模式

这个模式表面上看是个比较简单的模式，这个是Bob的见解。他强调Command模式具备“功能分解的味道”。实际上在《design patterns》里面command也是被归类在行为类的。通常的command接口定义：

public interface Command {

public void do();

}

从这个接口的角度讲，咱们根本不知道它的主要意图是什么，因此在一个类实现这个接口以后，这个类的动做意图，也一样被这个接口给封装起来了。Bob认为从面向对象角度，这是违犯天条的行为。但从上层抽象来讲，这又是很好的屏蔽了上层（caller）对具体实现的依赖。因此说，命令模式是一种面向动做的独立抽象，它能够很好地处理输入和动做调用方之间的隔离关系。

考虑到《敏捷》中的两个例子，例1复印机程序，传感器能够在不须要知道当前的事件具体是什么的前提下，直接调用绑定到事件上的command 接口方法。例2验证雇员信息合法性的实现。在增长每一个雇员信息到数据库以前都有对其全部信息的合法性进行验证。雇佣方式不一样的雇员，其相关信息也是不同的。如按小时工做的员工须要有相关的时间信息，而按业绩支付的也须要有相应的时间和数量，按月支付的员工则没有额外的信息。但在作增长一个雇员信息的事务时，能隔离掉对具体信息的依赖，能够减小这个事务代码实现的复杂性。《敏捷》在网上有电子书，各位能够对照着看看具体的架构实现。

针对《敏捷》中雇员事务的实现，来讲明一种可能比较常见的方法，首先声明，这里说明的方法，从必定意义上讲，是没有考虑面向对象这些设计的，而是咱们常常随手拈来写代码凑出来的习惯，写在这里，是想提醒本身，之后碰到这样的场景，应该考虑一下设计模式。看到这个需求，咱们的第一印象，应该是给雇员分类：

public enum EmployeeType {

HOUR(1),

MONTH(2),

COMMISSION(3);

private EmployeeType(int type){

this.type = type;

}

private int type;

public int getValue(){

return this.type;

}

}

而后在实现AddEmployeeTransaction时，判断加入的Employee的type. 跟Bob的实现相比，咱们少了什么，又多了什么？个人答案确定不是惟一的，不只是对这个需求的实现，还有前面这个问题。我来讲一下本身的见解：

1.过程性的思惟定势，使得AddEmployeeTransaction须要了解所有的可能状况，在种类繁多的状况下，可能会出现一个极其庞大，充满了if－else的大方法；

2.由于第一点，咱们确定建立了一个极其简单POJO 对象，不少人都会直接命名成VO（ValueObject）。

因而，各类所谓的smell就会出现。那么这个时候，咱们可能经过重构来抽取出一些小方法，来格式化一个庞大的方法。如此之多的方法是否在说明一个问题，一些行为是否能够造成抽象。由于咱们知道if－else比较多的状况下，要考虑command，strategy之类的设计模式，为何？由于这些模式都是面向行为的，而咱们就是在针对行为进行重构。

想到这里，忽然对《重构》这本人人喜好的书有点可惜，要是它里面能关联上设计模式方面的内容，可能会更具震撼力，由于行动加上理论依据更有说服力，也能够在老是学重构方法方式的时候能思考一下，什么样的重构推出来什么样的模式。

以上是个人我的看法，是作了7，8年的一个对本身编码方式的总结，后面的一些设计模式，也会带上我的色彩的自我剖析。

那么为何要讲command模式，固然接这个机会都学一遍，但在《设计模式》中关于Command模式的应用部分，其中的一种方式就是采用callback的方式来提供action perform，从而在时间上和引用上都隔离request和调用者。spring里面在阐述IoC的时候，尤为是关于jdbc的封装，它将具体业务相关的动做放到一个callback对象中，而JdbcTemplate能够在绝不关心具体业务动做的情况下，进行调用。

但愿这个关联，有助于加深对spring设计的理解。

 在part2，再讨论其余几个相关的设计模式，或许多少都会提一下。《设计模式》，《敏捷》，《Expert》这三本书再次捧在手上仍是引人入胜，只是如今不会再像之前那么急躁，那么不顾实际场景的使用。因为spring这个框架自己就是个集大成的模板，这是一个极好的机会能切实看到大师级的架构思路，因此后面看状况，若有必要，就一会儿把设计模式都过一遍。