什么样的人更伟大，站在巨人肩膀上的人---由业界思想进化的反思(原创)

什么样的人更伟大，站在巨人肩膀上的人---由业界思想进化的反思(原创)

什么样的人更伟大，站在巨人肩膀上的人。

   当 COM/DCOM 仅仅局限于 Windows 平台上时， CORBA 的跨平台应运而生；当 CORBA 开发部署应用过于繁杂时， EJB 石破天惊；当 EJB 测试不利侵入严重效率不佳开发成本依然很大之际， Spring 当仁不让。新事物的产生首先吸收了前人的优势，在此基础上不断完善改进，直到让不断成熟的用户群满意。

   从 EJB 说起，其技术承诺是解决 CORBA 的所有问题并降低其复杂性，其定位于大型应用，尤其是对高可靠性、分布式、远程访问、集群等场合。但一开始 EJB 提出并解决了 JavaBean 不具备的系统级服务的特性，并着实降低了 CORBA 的复杂性，也可以跨越平台，受到人们的钟爱，甚至在没有任何意义的情况下也在应用程序中使用到 EJB ，当使用不到 EJB 本身的扩展性好以及其它优点时，开发者群开始抱怨甚至倒戈 EJB 。这也符合历史，当狂热之后，便是思想成熟后的反思，反思驱使改良，改良就是进步。

   EJB 提出了 EJB 组件的生成、销毁、钝化、锐化、管理由容器来做，这本身就是依赖倒置的前身。当人们提出了工厂方法模式（生成单一对象）、抽象工厂模式（生成一系列对象）、 ServiceLocator 模式（查找某种已有的服务）等模式时，已经在使用这控制反转的思想。更甚者，人们提出了回调思想，用底层的框架调用上层的应用，而不是一般意义的上层访问底层， EJB 大量使用了 Callback 钩子方法，比如 EJBCreate ， EJBRemove 等；当 TemplateMethod 模式再次在应用中归纳出时，当我们这个也模版模式那个也模版模式时， Spring 将此运用到淋漓尽致，其封装 StatelessSessionBean 到 AbstractStatelessSessionBean 之类为开发者封装了 EJB 使用的侵入性时，我再一次感想，何以是思想真正得以了运用？！这些都可以关联涉及到 IoC 思想。 IoC 本质是为达到松耦合的目标，正在这个时候另外的一个思想 AOP 随着人们不断的推敲研究正茁壮成长着。

   OOP 面向业务逻辑，人们在 AOP 是否可取代 OOP 的摸索中，发现有许多比如日志、事务、安全等系统级的服务并不属于某个模块而是贯穿于整个业务，如果 OOP 比作是纵向的业务逻辑，那 AOP 岂不正是横面的服务。但是如何取得具备业务逻辑功能的业务对象？

   IoC 不正是把对象的创建、管理、销毁都放到框架容器中处理的么， IoC 与 AOP 的结合点一出现，就整个业界带来了前所未有的冲击。思想都是现成的，思想的发展升华却是空前的。 EJB2 终于被批驳的体无完肤，虽然有些不合理， Spring ， HiveMind 等一大批优秀框架竞相而出，不是喧闹，而是对应用的经验的累积。 EJB3.0 也走上了这条路。更有甚者， JBoss 推出了 MicroContainer 容器，以打破服务迁移的困顿。

   站在巨人肩膀上的人才是更伟大的，无论是 IoC 还是 AOP ，概念是新的，但是其思想的应用却早已出现，甚至有变相的应用，但却没有突破了以前的圈子。说成一个是改良一个是革命，应该不属为过。量的累积导致质变的过程也得以体现。

   由此不由得想起 JDK 提供的 reflect 机制，当 JDK 牛牛人指定并推出后，当 JBoss 创始人灵光一闪，推出 JBoss 后，反射机制被人们认识到，而刚刚说的又哪个离开了反射？！

   呵呵，看来，巨人的肩膀扛起一波又一波的人是没有问题的，我们开始攀登？！呵呵。从业界的发展看，浮躁是不利的，累积总结深入到底层本质方是正确之道。

新补充续篇：

什么样的人更伟大，站在巨人肩膀上的人---由业界思想进化的反思(二:IoC价值强化篇)