读书笔记（J2EE Development without EJB）

《J2EE Development without EJB》

Ø 在某种意义上，J2EE是现有中间件技术的发展演化。

Ø J2EE和EJB的很多问题都源自它们“以规范为驱动”的本质，历史告诉我们：最成功的标准都是从实践中发展来的，而不是由哪个委员会创造出来的。

Ø 我们应该尽量降低架构的复杂度，只为现实的(和合理可预见的)需求提供支持，不要试图预先把所有的问题都考虑进去…重视架构的重构。

Ø 在耗费太多的钱和时间在推荐的体系结构上面之前，我们应该始终“问问电脑”对这个体系结构究竟是怎么想的。

Ø “帕累托法则”，花较少的(10%~20%)力气解决大部分问题(80%~90%)，架构的价值在于为常见的问题找到好的解决方案，而不是一心想要解决更复杂也更为罕见的问题。EJB的问题就在于它违背了这个法则，为了满足少数情况下的特殊要求，它给大多数使用者强加了不必要的复杂性。

Ø 大多数J2EE代码生成工具所生成的代码都是用于实现J2EE经典架构的，容易犯的错误是：代码重复、过渡工程等

Ø 想依靠代码生成来补救糟糕的框架，这种想法是尤其危险的

Ø 不要使用比一个完整的示例更复杂的起点。

Ø 一个好的开发工具应该具有：优秀IDE、单元测试工具、标准构建工具、好用的XML编辑器、源码控制系统。

Ø 一个成熟的架构中必须包含一个严格定义的服务层，它必须具有：完备、简单、以接口形式、面向对象、易编写、事务管理、横向可伸缩性、便于测试、不依赖任何特定底层数据访问技术。

Ø 尽可能的把无状态服务层设计应用于系统，尽可能把状态保存在Web层而不是业务逻辑层。

Ø 不要在Web层中(用Struts
Action之类的东西)实现业务逻辑。业务逻辑应该独立于表现层。

Ø 应该并置业务对象和Web容器，这是最简单、最高效、最符合面向对象原则的一种方案。J2EE开发者中有一种根深蒂固的认识：业务对象应该和Web层物理上分开，这种谬见危害极大、代价极高。

Ø Web层应该很薄，应该搭建在服务层上面，其代码只是用来解释用户的操作、显示响应的结果。

Ø 所谓侵入性，是指容器强制业务对象采用特定的接口，例如EJB容器要求EJB组件具有EJB接口。

Ø 工具上的复杂性是危险的，选择最简单的工具，就跟尽可能选择简单的架构一样，能带来真正的价值。

Ø 对于软件的“架构”而言，实现架构时会遇到形形色色的问题，而解决这些问题则需要具体、详尽的细节知识；只有掌握了所有这些细节知识，才能够确定整个系统架构。所以，如果架构师把时间都花在编写文档、搭建模型上，那也就很难做出切实可用的架构。

Ø 一个架构可达到的简单程度，应该取决于业务需求，而不是技术平台。理想情况下，在项目周期的前期，架构满足业务需求的能力就可以用经验方法评测出来，而不是全凭主观臆断。

Ø 一个组件是一个可以替换的软件单元，它通过接口以及接口的契约来定义。应该可以由一个组件切换到另外一个满足同样契约的组件，而不影响系统其他部分的正常工作。

Ø EJB让搭建分布式应用变得简单，却也让它变成了一种危险的诱惑。

Ø 并置(collocated)，指整个应用运行在同一个JVM上。

Ø 在J2EE的缓冲池中，真正有价值的是资源池，而不是业务对象实例池。

Ø YAGNI思想：不要为尚未出现的复杂情况预先做出过多的准备，因为这些想象中的复杂情况也许永远不会出现。

Ø 很多时候，标准是有利于行业的；但是有些时候，它们抑制了创新；还有些时候，它们把糟糕的技术奉为规范，而且使很多开发人员盲目轻信标准，而不是亲身探索解决方案的利弊。

Ø “降低对运行环境的依赖”至少跟“建立标准的运行环境”一样重要。

Ø 不要随便组合开源产品，除非已经有这样一种常见的组合方式。
 
《Effective Java》

Ø 实际上，clone方法是另一个构造函数，你必须确保它不会伤害到原始对象，并且正确的建立起被克隆对象中的约束关系

Ø 如果你改写了一个非final类的clone方法，则应该返回一个通过调用super.clone()方法而得到的对象

Ø 非可变对象本质上是线程安全的，它们不要求同步，可以自由的被共享。

Ø 一个类要在内部使用某些常量，这纯粹是实现细节，实现一个常量接口，会导致把这样的细节泄露到该类导出的API中，对用户也没什么价值。

Ø 保护性的设计程序，对构造函数的每个可变参数进行保护性拷贝是必要的。

Ø 在循环中经常要用到最小化变量作用域这一规则。

Ø 异常只应该用于不正常的条件，它们永远不应该被用于正常的控制流。

Ø 高层的实现应该捕获底层的异常，同时抛出一个可以按照高层抽象进行解释的异常。这种做法被称为异常转译。

Ø 为了避免死锁，在一个被同步的方法或者代码块中，永远不要放弃对客户的控制。

Ø Object.wait()方法的作用是使一个线程等待某个条件，总是使用wait循环模式来调用wait方法。永远不要在循环的外面调用wait。

Ø 编写健壮的、响应良好、可移植的多线程应用程序的最好办法是，尽可能确保在任何给定时刻只有少量的可运行线程，线程调度器就不会有更多选择。

Ø 不要企图通过Thread.yield()来修正程序，这样的程序是不可移植的。

Ø 实现Serializable而付出的最大代价是，一旦一个类被发布，则改变这个类实现的灵活性将大大降低。第二它增加了错误和安全漏洞的可能性，第三相关的测试负担增加了。

Ø 当你编写了equals方法之后，应该确保它是对称的、传递的、一致的