格式有点乱.DOCVIP

Expert One-on-One J2EE Design Development 第一章 1、运用J2EE技术实现OO设计，而不是让J2EE技术支配对象设计。 2、企业级体系结构的目标：坚固的（可靠、无缺陷、高质量代码）、可工作及可伸缩、利用OO设计原理（提倡使用可复用解决方案-设计模式）、避免不必要的复杂性（XP：可能管用的最简单事情、不过度设计）、可维护可扩展（维护是代价最高的阶段）、按时交付、易测试、可重用、对多种客户端支持、可移植（服务器间可移植）。 3、误解：J2EE必须是分布式的。 4、分布式好处：共享业务对象、部署任一构件到任一物理服务器上的能力。 5、分布式缺点：性能问题、复杂性、实行OO设计方面的限制。 6、EJB只是J2EE的选择之一。 7、EJB缺点：难测试、难部署、使用具有远程接口的EJB可能会妨碍OO设计的实施、使用EJB可能使简单的事情变复杂、应用服务器选择减少。 8、使用EJB可疑理由：为了通过把业务对象暴露为EJB来保证干净的体系结构、为了允许给数据存取使用实体组件、为了开发坚固可伸缩的应用。 9、使用EJB充分理由：为了允许构件的远程访问、为了应用构件部署到多台物理服务器、为了在异步模型适用时实现消息消费者。 10、按情形考虑EJB使用的理由：为了使开发人员避免编写复杂的多线程代码（非决定性理由）、CMT（决定性理由）。 11、一定要涉及到Java接口，而不要涉及到具体类，也不要设计到具体技术。 第二章 J2EE项目的选择与风险 1、多种技术的集成本身就有风险、引进新技术风险。 2、依据规范版本开发一个策略：该应用的性质、该项目的期限、该组织的性质、可移植性。 3、降低风险，避免选择未经证明的新技术。 4、标准化服务器选择。 5、可移植性：应用在应用服务器之间的可移植性、应用在服务器操作系统之间的可移植性。 第三章 J2EE引用的测试 1、编写单元测试原则：编写测试到接口、不要自寻烦恼地测试JavaBean属性、最大化测试覆盖率、不要依赖测试用例的排列顺序、避免副效应、从类路径中读取测试数据，不要从文件系统中读取、避免测试用例代码重复、何时应该编写“stub”类、继承性与测试（分级）、测试用例应该放在何处、测试策略应该影响编写代码的方式吗。 2、一个严格的单元测试策略对编程风格可能会有什么样的含义：保证类没太大的责任，太大责任使测试复杂、提醒我们类实例变量只能通过方法修改、就继承而言，它促使我们实现更严格的封装、有时促使我们添加纯粹的为方便测试而设计的方法。 第四章 J2EE项目的设计技术及编程标准 1优质代码：无需大修改也是可扩展的、易阅读及维护、有齐备的文字资料、易测试、易调试、无代码重复、可重用。 2、不仅必须保证我们编写代码正确，而且还必须保证我们编写正确的代码，进而在适当的地方利用已有的解决方案。 3、OO设计比任何一项特定的实现技术都重要。好的编程习惯和健全的OO设计使好的J2EE应用具有坚实的基础。劣质的Java代码就是劣质的J2EE代码。 4、请抓住一切机会向贵公司内外组织的其他人所编写的优质代码学习，专业程序员或设计师更重视学习和发现最佳解决方案。 5、利用接口实现松耦合，即“面向接口编程而非实现”： 修改任一应用对象的实现类同时又不影响调用代码的能力。这使得我们能够在不破坏其他构件的同时参数化一个应用的任何一部分。 实现接口方面的总自由度。不必束缚于一个继承性分级结构。但是，通过在接口实现中使用具体的继承性来实现代码重用仍是有可能的。 必要时提供应用接口的简单测试实现与桩基实现的能力，进而使其他类的测试变得更方便，而且使多个团队能够在他们对接口取得一致性意见后能并行工作。 采用基于接口的体系结构也是保证J2EE应用可移植性的最佳手段。 基于接口的体系结构可与配置反射的使用有效地组合起来。 6、优先对象组合而非继承： Java分具体继承性及接口继承性（接口实现） 接口的继承性允许多态性：运行时用相同接口替代对象的一种可替代性。这还提供了面向对象设计的主要价值。 具体继承性允许多态性，又允许便利的实现。代码能够从一个超类中被继承。因此具体继承性是一个实现问题，而不是一个单纯的设计问题。 具体继承性具有以下缺点：当我们需要一个简单接口实现时，却强迫用户扩展一个抽象或具体类。这意味着我们使用户代码丧失了它的继承性分级结构的权利。如果正常情况下一个用户将需要它自己的定制超类是毫无道理的，我们可以为子类化提供方法的一个便利抽象实现。因此，这种接口方法不抵触便利的超类的规定。 通过子类调用父类的助手方法，使用具体继承性来提供助手功能度。如果继承性分级结构外部的类需要助手功能度，怎么办？使用对象组合，以便助手是一个独立的对象，并且可共享。 使用抽象类来代替接口。抽象类得到正确使用时