Rod Johnson说：设计一个业务对象带有远程接口、具备分布能力的应用程序，这是对OO的严重破坏。我想请教一下为什么？

Question

因为他讨厌ejb啊，serverside这般人确实都是高手，高手就是有点狂

Answer 1

我把整段贴出来了，大家看看，看懂的提示我一下
让我们来看两个例子，看看很多J2EE是如何背弃了OO的原则：
􀂉 使用带有远程接口的EJB，以便分布业务对象。设计一个业务对象带有远程接口、具备分布能力的应用程序，这是对OO的严重破坏。出于性能的考虑，带有远程接口的组件必须提供粗粒度的接口，以避免频繁的调用。另外，它们还需要以传输对象或者值对象的形式传递输入和输出参数。的确有．．．一些应用必须提供分布式的业务对象，但大多数应用并不需要这样做，它们最好是让业务对象呆在自己应该在的地方。使用分布式对象的问题并非EJB一家独有的，EJB不是第一个分布式对象技术，也不会是最后一个。这个问题之所以总是和EJB联系在一起，是因为组件的分布恰好是EJB处理得比较好的几件事之一——也许好得过头了。

Answer 2

我觉得因为是粗粒度的接口，必然降低代码重用度，这一个接口的内部逻辑处理可能非常复杂；另外一点，这个接口无疑是EJB容器提供的，这样就增加了耦合度
随便说说，不知道对不对

Answer 3

主题文章: 我没有使用Spring  在这里，Spring指的是Spring开发框架，一种依赖注入容器的实现。首先，我声明我没有一点冒犯Rod的意思（你是个优秀的人）。但是坦白地说，我不能狂热的追随您的开发框架。更为严重的是，我注意到，我所考虑的这些可能对于Spring框架的使用率来说是危险的，并且有可能降低对Spring框架的使用率。我读到一个关于Spring的很重要的文章或书籍，看起来好像除了我，所有的人都喜欢Spring。但是我有什么损失吗？可能采用Spring是J2EE一个类似“膝跳反射”的事情（这种事情可以不经过大脑）。“J2EE不是好东东，Spring的人说他们的产品更好一些，所以Spring一定是好的”但是事情并不是那样的。第二点，我仅仅讨论Spring，而不讨论依赖注入。我喜欢依赖注入，并且每天都使用它。它是一个摆脱service locators的好方法。
我记不得有多少次有开发者对我说，“我的上一个项目使用了Spring，这个框架真好”。但是没有人能清楚明白的说出他们究竟喜欢Spring的哪一点，Spring到底帮助了他什么。所以我敢说，他们喜欢setter注入，这使得他们的代码更加灵活和可测；但并不一定必需Spring。我猜有些人并没有彻底理解依赖注入，所以他们依赖Spring来帮助（或者强迫？）他们使用依赖注入。然而，这种好处并没有在量上大于Spring在你的代码上带来的负面影响，这些负面相应在下面的清单上。
Spring的狂热者公开的指责J2EE，但是从他们的指责中，我可以说，Spring实际上既不是轻量级也不简单。Javadocs未必是必要的，但是这一切都要怪罪于一个用户API吗？最起码J2EE清晰的将API和它们的实现分离开来。Spring的鼓吹者吹捧Spring不会“动”你的代码，例如，你不必去实现任何的Spring指定的接口（生命周期接口除外等等）。新闻特写，“XML配置文件是我们自己的代码，通过它，我们能组织起很多的代码，这些代码都是Spring给定的”
为什么我一定要把我所有的依赖使用XML文件来表达？我是需要把我所有的对象都用Spring来处理，还是仅仅一些没有考虑成熟的？上面我所说的这些问题，Spring文档没有给出一些可靠的答案，而且所有的Spring书籍也没有给出。我假定我们使用Spring是为了产生所有的对象。那么这样还是我们喜欢的Java编程吗？我希望在编译期和随后的装载期能够确定这些对象，而不是在运行我的代码的时候才能够确定。Spring能做到支持这些吗？
很明显，我希望装载一些像JDBC驱动这样的动态实现的依赖（即不要求编译期的检测）；但是在我的系统中，这样的依赖只是一小部分；而剩下的部分，我们代码的绝大部分却不是。我是在使用一种强类型的语言。如果我希望像Spring那样，我会使用Ruby。难道Spring的配置文件不像是我们在猜测着将Java代码写入XML文件里吗？难道那些使用Spring的开发者使用起Java来不那么舒服？我确信增加了一个XML层并不能使得代码变得哪怕是一点点简单。
现在回过头来谈谈关于对Spring API的依赖的问题。我不得不调用容器来产生我的第一个对象（假定剩下的Spring管理对象是注入的），不是吗？我需要一些方法在编译期间来测试我所请求的对象是正确的类型；我不想靠抛出违例的方法。究竟，我真的需要一个容器吗？在Spring里，你通过使用一个唯一的ID来获取对象。我假定大部多数的开发者在他们Java代码里使用一个String类型的常量来定义他们的ID。Spring并不能帮助我使得我的Java代码里的ID值和我的XML文件里的ID值保持一致。当一个对象已经够用了的时候，为什么要使用两个对象？是否我们真的把所有的信息组织到一起放到了容器里？是Java的包和类不够用了吗？
还有一个困扰我的问题是，在我的XML配置文件里，我不得不引用Spring实现的类，我不想管这些东西。在Spring的计划里，我听说更加简单的、域范围的XML将在2.0版本中被使用，但是我到现在还没有看到。为什么这些不能早一点被采用呢？
什么继承上的东西啊？关于超常类名置换的变换。但这些都不是我的风格。
Spring在哪里支持了JDK1.5的泛型？我知道你有很多客户运行在JDK1.4甚至JDK1.3的版本上，但是这和JDK1.5没有分歧啊。泛型打开了通向像这种框架的各种各样的可能性的大门。这些是我最喜欢的JDK1.5的新特性，拥抱这些新特性吧！
你曾经看过每次你产生一个对象Spring要做多少事情吗?我需要在运行期内有少量的instanceof，而大多数是在装载期的Class.isAssignableFrom()。不是因为内部的实现给最终用户带来了很多的麻烦，而是因为把它作为了一个测试框架剩下部分质量的试金石。一个好的对于bean的创建渠道的重构将会很容易的被遵循和产生更加高质量的代码，并且不需要求助于更多的继承就能被重用。
Auto-wiring也有同样的问题。每一个人真的在使用它吗？或者是为未来的重要功能的一个铺垫？
Spring是怎么处理领域范围的？我听说在2.0版本中，Spring最终会支持HTTP request和session的。我很惊讶难道现在这些没有被支持吗，那么Spring的用户在整个期间里都做了些什么。难道是新的版本将使我能够定义自己的领域范围？例如，它将实现我想要一个“conversation”领域范围，就像Seam将要支持的那样。我们将不涉及MVC或者AOP框架。幸运或者不幸的是在某一时候，我将不使用一个依赖注入容器。难道不认为PicoContainer已经远离了简单二字。它也和Spring有同样的问题，我认为Aslak和Jon已经转移到了Ruby的领地。还有其他的开发框架没有这样的问题吗？
幸运地，简单的采用依赖注入设计模式能让你完成Spring的90%的工作，特别是当你在并不急于使用它的时候。这是我推荐的方法。我的确没有看到让我自己马上使用Spring的理由。没有它我工作的很好。如果你在使用它，那么请你把眼睛睁大一些，使用怀疑的、鉴赏的目光。如果仅仅因为某人有流行的开源框架，他们有很好的市场，并且他们被一些大的公司支持（IBM在很多年前就推荐我使用Struts）。但这并不意味着他们知道什么工具对你最好，尽管他们比你知道什么是更好的。
原文链接：
http://crazybob.org/2006/01/i-dont-get-spring.html

Answer 4

Rod Johnson多次强调OO的重要性，强调OO比J2EE重要的多
书中也多处会提到某某设计违背了OO原则，大多他也没解释原因，我看得一头雾水
看来我这块要好好补一下了

Answer 5

书中在后面的章节提到了一些原因，主要是：
1。分布式会给业务对象接口强加一些限制，会使原本单一的继承体系变的复杂
2。分布式应用在远程调用中经常使用传输对象模式（Transfer Object），而作者认为TO不能算是真正意义上的对象，因为它只有对象的状态，没有对象的行为