BEA WebLogic Workshop 8.1和设计模式

    您可能是一位BEA的客户，如果您正在阅读本文，您可能想知道新的BEA WebLogic Workshop 8.1是如何影响您的设计模式考虑的。首先，WebLogic Workshop是IDE，因此前面有关IDE的章节同样适用。对这些讨论感兴趣的Workshop的两个额外方面是控件和预实现的设计模式。

    WebLogic Workshop Controls是打包功能的一种方法，可以轻松将其包含到使用Workshop IDE的应用程序中。打包包括IDE必需的可视元素、运行时行为、要求的配置等等。控件是如何影响设计模式应用的呢？还记得设计模式在前面划分为isolated use和broad exposure吗？划分到isolated use类的设计模式可能被打包成 Workshop Controls。把设计模式作为控件打包可使 Workshop IDE的其他用户共享实现，从而避免了每一个Developer/Project AntiPattern中的实现。

    您可能想知道为什么broad exposure设计模式为什么不可以作为控件实现。原因是broad exposure设计模式导致创建了许多其他类或者独立于其他应用程序。这种情况就不适合控件的即插即用方面。broad exposure设计模式的采用应当三思而后行，一旦采用就不能轻易取消。这些要求不符合WebLogic Workshop Control的目标。

    WebLogic Workshop还具有很多预实现设计模式，如Pageflow和用户接口结构。在Workshop 中，您可以创建JSP和定义Pageflow来控制Web应用程序页面之间的定位。在这种情况下，WebLogic Workshop使用流行的Apache Struts 表现层框架。Workshop的这个方面（使用 Struts）提供了一种Model-View-Controller（MVC）设计模式实现，意味着不用创建自己的MVC实现。Workshop包含的其他功能很可能替代您自己的设计模式实现。尽管一些设计模式实现的开盒即用很好，但是应当验证不仅实现而且实现创建的WebLogic任何依从性也非常合适。

    成功采用设计模式的三个步骤

    如何把设计模式的采用和日益临近的最后期限、紧缩的预算和很多公司现有的有限团队资源相结合？以下是成功制订设计模式的三个步骤。

    强大的通信和培训

    许多机构拥有领先技术，可能正式通过了设计师论坛的论证或者非正式的公认专家。这些领先厂商将推广设计模式采用中的开放通信，并将培训开发具体设计模式的团队。通信应当跨开发团队和项目以便预先防止采用竖井和多种惟一的实现（谨记每个Developer/Project AntiPattern的实现）。培训可以采用正式的internal lunch-and-learns、正式的internal class或者派一些员工参加外部培训。这些培训方式将促进正确的设计模式应用程序。如果仅有极少的观众能够参加培训，非常好的的候选人是那些感觉适合在回来后能够培训其同事的人。

    设计模式采用指导

    设计模式可用于使项目受益，但是他们也可能因为误用而对应用程序造成损害。应当鼓励采用他们，但是对其的采用应当受到审阅和验证。设计模式可以包含在设计和开发过程中。在任何一种情况中，设计模式的使用应当由审阅者确认和验证。在审阅过程中还可能会遇到这样的情况，额外的设计模式不适用于最初包括的地方。即使环境中没有进行正式的审阅，这一步骤也可以通过同事审阅或者团队讨论来完成。这一步骤中的审阅者要么是主要团队的成员，要么与他们建立开放通信。

    指导采用对于broad exposure类别的设计模式非常关键。这些设计模式具有很多相关的风险，因为他们将创建依赖性。这些依赖性可能在一些对象类中，例如，只工作在更加广泛的DAO设计模式实现范围中的数据访问对象（DAO）、或者跨应用程序边界（如使用Value Object设计模式在应用程序和应用程序层之间传输数据）。这些设计模式也可以由项目中的其他人或者不同项目的人实现，而且实现应当重新使用，不同于创建另一种独特的实现。

    重用实现,不只是设计模式

    只要在创建自己的设计模式实现中有一定的满足，团队和公司就可以在重用发生在代码层时，而不是设计创意层时获得更多益处。使企业获益的最初设计模式是改进的实现。但是，真正的目标是重用实现。重用实现将导致：a)其他可重用的类（取决于公共实现）；b)缩短开发时间和降低成本；c)缩短维护时间和降低成本；d)在应用程序之间和内部轻松集成。

    这种重用对broad exposure设计模式非常重要（有时是基本的）。这些设计模式创建了外部依赖性（集成将从公共实现中受益）或者产生全部的自定义类库（如果有公共基础将可重用）。isolated use设计模式也可以从重用中获益，但是如果他们是根据具体情况定制的，他们就非常难以重用。

    有时您可能会问自己：“如果重用比较好，为什么设计模式和可以重用的实现不可以一同应用呢？”在我们讨论设计模式如何使更多读者获益的时候才会讨论这个问题。如果可能，如果已经预定义了实现，那么达到广泛适用性这个目标就会非常困难。然而，一旦设计模式被应用到特殊的问题域或者技术基础设施中，那么就可以重用在该环境中产生的实现。

    架构中的设计模式

    这看起来像是一件可怕的任务，需要掌握设计模式如何应用在实际情况中，如何构建优质的实现，以及如何促进重用实现。完成该任务的方法之一就是在环境中引入应用程序架构。应用程序架构提供了应用程序需要的结构，从而使开发团队可以关注应用程序的域逻辑。这包含了已实现的设计模式。除了重用设计模式概念或者单个实现之外，可以在多个项目和应用程序之间重用架构。这种共享的公共实现确保了兼容性，并为开发和维护多种不同的实现提供了一种低成本替代方案。兼容性提供了重新使用需要的技术基础。没有足够的篇幅在这里深入讨论架构的其他重要品质，如运行时监测和管理、可配置应用程序逻辑和适应性行为等。您可以从Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/ata/ata_init.html) 中学习到更多有关架构的知识。

    结束语

    设计模式是一种令人惊异的资源，应该使用他以增加您的优势。虽然设计模式提供了可重用的概念，但是面临的挑战是决定使用哪一种设计模式和致力于可以重用的实现。通过了解采用设计模式中会产生的风险，就可以在继续学习和实现更多设计模式时避免风险。按照本文概述的步骤会产生一个流程，用于在团队和机构中推广成功的设计模式采用。