Java瘦身之路

在使用Java开发的过程中，开发者希望拥有功能强大而易于使用的框架。从EJB到Spring，Java向着这个方向不懈的前行着。

很多人比较迷惑轻量级框架（lightweight framework）的定义，其实，它没有一个严格定义，轻量一词只是反映我们对技术拥有强大功能的同时更易于使用的一种美好愿望。

回顾Java的发展历史就会明白：让大家对正常的轻量产生如此迫切要求的主要压力来自于EJB。这里并不是说EJB不好，而是太好了,功能非常强大，但是只注重功能强大，忽视易用。

在EJB技术之前，我们开发一个复杂Java企业应用系统时，会在代码设计中充满各种底层技术的味道，或者说，那时的Java更象C++，Java企业应用开发者需要学习更多更全面软件技术才能动手编程。

EJB则将很多底层技术：缓存、池、安全以及事务封装在特别的EJB服务器中，从这点上解脱了开发者的工作。在这个时代，Java技术重心就在于J2EE服务器，或者称应用服务器，中间件服务器。各个厂商争相研制功能强大，能够支持几十台集群计算的EJB服务器，并以次为荣，Bea的Weblogic是这方面的佼佼者。

EJB问题也就随之暴露出来了，在EJB2.1以前，复杂的XML配置；各种稀奇古怪的调试运行问题使得EJB开发调试变得非常不容易，开发者经常在错误信息中迷失方向。这时，对于普通开发者，EJB2.1以前的开发变得沉重，Java世界弥漫着一种沉重的气氛。

首先打破这种沉寂的是Spring，Spring打着“轻量且简单”这一极具号召力的口号横空出世，可以说恰逢其时，很快赢得了广大开发者的响应，虽然这场摒弃EJB运动中有时过于极端，但是至少表达了大家对EJB 2.1的不满，虽然在EJB阵营聚集了软件开发领域最顶端的厂商：IBM、BEA、甲骨文、SAP、SUN等，但是开发者还是坚决地说“不”，并且进行了自己的选择。

尽管在这场运动中，轻量化的EJB3.0很快问世，但是我们还是很有必要思考一下：开发者到底需要什么样的技术才能在瞬间变化的发展潮流中坚持自己观点，而不是人云亦云，迷失方向。

轻量级框架特点

“轻量”本身是一个非常感性的词语，它随着技术发展不断更新，比如对于一个初中生，加法计算就是很轻量的；可是对于幼儿来说，则可能沉重的。轻与重可能因开发者而异。

但是，让科技变得更简单易用的方向是没有错的，总的来说：一个轻量级框架应该使得开发者将更多精力集中在业务开发上，而且多快好省地完成稳定而且灵活的产品开发。

轻量级框架需要体现功能强大而易用，注意在这个定义中，首先是功能强大，然后才是易用，这才体现“大道至简”的原则。功能强大在软件中意味着良好的设计，意味着灵活性，意味着软件的高质量。企业软件必须容易维护和发展，这样才能帮助企业成为百年老店，在企业IT长时间发展中，硬件设备可以通过资金投入更换，但是软件只能在原来基础上拓展，而不能彻底推翻重来，但是如果原来软件的拓展性很差，就造成了“巧妇难为无米之炊”的痛苦。

在Eric Evans的《领域驱动设计》一书中专门探讨了这样提供灵活设计的模式和方法。

明显意图的接口

接口的名称必须表达明显意图，而不是模棱两可，接口虽然是抽象，但是也不能抽象到不知所云， 如果其他开发人员必须查看接口的实现子类才能搞清楚你这个接口的意图，那么你的接口抽象无疑是失败的，使用明显意图的接口可以将整个子领域切分成一个个单独模块，每个模块使用带有明显意图的接口封装起来， 这种切割方式用来调整项目的焦点和对付大型系统的复杂性。

边界影响

在软件开发中，操作分为命令和查询，命令就是能够使系统状态发生改变的操作，如增删改等操作。这些操作都可能需要有副功能，如希望增删改完成后还要返回一些结果，这些主要功能之外的副业，也称为边界影响。一些传统过程经验的程序员经常喜欢搞“一机多用”，喜欢将很多功能揉合在一起。

大多数操作会调用其他操作，造成任意深度的嵌套，这样形成一个树形结构的调用关系，这就容易使我们很难预测调用一个操作会产生什么样的结果，调用一个操作变得谨慎，甚至战战兢兢，虽然Ioc或DI使得这种嵌套关系的管理变得容易，但是不能保证每个操作本身的设计能降低复杂性，后者就是我们现在关注的。

为什么我们调用一个操作时会变得小心?因为这个操作设计时可能不执行主要功能，还有其他副功能，这些副功能可以认为是一种“多余副作用”。

解决办法很简单：设计这个操作时消灭副作用;如果不能消灭，就将其分离并单独表达出来。

如果边界影响不能通过设计避免，那么我们就直面它，在增删改等命令执行同时返回数据时， 我们就需要通过断言来约束我们的设计，通过断言能够易于使用单元测试Junit等工具测试。从而保证你的命令简单有规则。

总之，还是那句有些哲学意义的话：对于边界功能，首先要去除它，如果不能去除它，就承认它，但是同时会约束它。

边界影响主要的是服务接口怎么做的问题。在实际项目中，模型和服务是相互结合不断重构的。那么模型和服务粒度是如何界定的？

对象的粒度到底是多大？这没有一个统一的规律，哪些属性或行为属于A对象，哪些属于B对象，有时又需要将这些属性和行为分离以便能够灵活组合。我们一般很难确定类的粒度到底是怎样规模表示达到设计目的？

粒度不能太大，避免造成重复和冗余，很多概念混在一起;当然粒度也不能太细，以至于太碎，不能完整表达一个领域概念，例如半个铀原子就不再是铀。

类需要尽量准确表达领域概念，大多数领域中都包含某种逻辑上的一致性，而很多开发者有时只注意单纯的设计原则，忽视领域逻辑，设计思考时需要两条腿走路，实现平衡。

所以，类的粒度是要能够反应领域的概念轮廓，将能够反应概念轮廓的那些重要元素聚合到当前正在设计的类中，这也是设计中高聚合原则的体现。

高聚合、低关联是两个设计基本原则，上面我们谈了如何做到高聚合，实际上，也是反映一种类或模块的粒度设计规模。

消灭依赖

复杂的依赖关系无疑提高了系统的复杂性，加剧我们大脑负载，所以，我们的模型之间关系必须精练，减少依赖，最后保留下来的依赖代表了领域概念之间某种根本的关系。有的系统中，甚至是零关联，从而得到一个个被完全孤立的单独的类，这才是方向。

每个依赖都是值得怀疑的，这是我们思考的前提。重构时，一个个去消灭那些象蜘蛛网一样密集的关系，斩断它们，低关联时减轻概念过载问题的基本方法，孤立类是低关联达到极致的一种标志。

减少依赖不是意味不考虑业务领域场景概念而去武断的实现。依赖和之前描述的边界影响一样，有时确实不能消灭，那么我们就承认它，但是会又有一套设计原则来约束它。

瘦身之路

在简化方面，Java世界提出的POJO思想，可以说是简化方向，POJO实际就是普通的JavaBeans，这是相对EJB提出的，因为在EJB2.1中，JavaBeans或Class不再是自由自在的独立类，它必须依赖附属于EJB2.1框架，我们不能因为需要集群功能，而放弃原来简单好用的JavaBeans。

具体来说：轻量化的企业Java框架是使用POJOs来实现数据访问和业务逻辑，没有其他隐含的类或接口需要继承或实现，这类框架一个特点是：Ioc或称叫做Dependency Injection(DI)，通过Ioc模式的使用，所有的POJO可以实现最大化的松耦合。

DI使用轻量化的框架容器将服务或其他对象注射进入POJO。这样，所有对象实例的创建和管理由容器实现，这样，大大减轻了开发者的工作，试想：一个普通系统有200个POJO类是正常，在开发调试中，经常在这些类之间调换变化，使用轻量框架，我们只要移动这些类的接口就可以，而不必将这些类的创建等代码进行变动。

68476636-8007）