第1章J2EE设计模式 模式能改进开发人员之间的通信,使他们可以更快地学习,从而开发更好的软件 为了达到高效通信,我们要用某种方式表示模式,最好使用标准格式。稍后将介绍 表示模式的格式 模式叮以按照质和量验证知识,从而评估其价值。这样町以表示与理解模式及所建 体系结构的利弊 模式几乎无所不在。多年来,出现了多种不同的软件模式,包括 ·设计模式,包括软件设计,可能是最重要的模式。通常是面向对象的,包括体系结 构(系统设计)、设计(组件交互)和编程(特定语言技术)。本书主要介绍设计 模式。 分析模式,描述可复用分析模型,在域分析中非常有用,涉及各种域,包括交易、度 量、会计和组织关系。要了解分析模式的更多信息,见《 Analysis Pattems: Reusable Object Model》-书, Addison-Wesley出版(ISBN0-201-89542-0) 过程模式,描述软件过程设计。具体地说,它们描述开发软件成功而经过证实的方 法与活动。详见剑桥大学出版社的《 Process patterns: Building Large- Scale Systems Using Object Technology)(ISBN 0-521-64568-9)<More Process Patterns Delivering Large-Scale Systems Using Object Technology)(ISBn 0-521-65262- 6) 组织模式,描述组织与项目的结构和实践。详见htp:/i44pc48.nfo. uni-karlsruhe. de/ cgi-bin/OrgPatternso ·实现模式,描述实现概念。详见《 Essential Java Style: Patterns for Implementation 书, Prentice Hal版(ISBN0-13-085086-1)。 ·其他域特定模式 模式还可以根据包括的问题分为: 创建性模式 结构性模式 行为性模式 可以看出,模式有几个抽象层,可以按不同方式分类。本书主要介绍J2EE设计模式 首先介绍设计模式。 何谓设计模式 设计模式是情境中标准设计问题的重复性解决方案。设计问题必须进一步调查之后才 能解决。问题通常发生在定的环境或情形中,称为情境。解决方案是这些问题的答案,帮 助我们在一定情境中解决这些问题。 例如,假设有一个小房间,问题是把门放在哪里更方便。经过不同测试之后,我们可 能发现应把门放在房间的东南角。这样就找到了特定问题的解。同样,软件设计中也可以找 到特定问题的解
实用J2EE设计模式编程指南 设计问题的解是否都是设计模式呢?不一定。设计模式只是适用于不同情境的解,即 可以重复采用,在不同情境中解决同一问题。 回到房门的问题,这个解还不能作为模式,因为它只限于这个特定情形。但如果能对 所有小房间找到一般解,则可以称为模式。 Alexander就是这么干的。他发现,房门不能放 在墙上任何地方。此外,房间的成功很大程度上取决于门的位置。因此,他建议除了很大的 房间之外,房门应尽量靠近墙角。他把这个模式称为角门( Comer doors)模式 虽然这是一个简单概念,但定义设计模式并不容易。因此,人们提出了五花八门的定 义。为了深入了解设计模式,下面再进一步解释。 设计模式针对软件设计,系统化地命名、解释和求值重要软件设计。设计模式使成功 地经过证明的设计与体系结构更容易复用,使新系统开发人员能更方便地釆用设计模式,特 別是经验较少的开发人员。设计模式能帮助我们选择不同设计。本书主要介绍设计模式,因 此此后“模式”一词特指设计模式 假设要开发 Customer实体Bean,并把客户数据提供给客户机。自然方法是用细粒方法定 远程接口(如 get/setNameO、 get/setAddres0),让远程客户机直接访间这个实体Bean。要 确定这个解不可伸缩,因此不适合实际应用,需要实现组件与客户机,进行部署和测试,需 要进行大量工作。记住,实际应用程序中通常要面对多个组件,而不只是 Customer 知道 Value Object!与 iSession Facade之类的设计模式之后,就很容易看出EJB的远程接口 应是粗粒的。 Value Object(数值对象)模式显示了如何使接口变成粗粒,同时以巧妙的方式 传输所有必要的数据,避免多次远程方法调用。 Session Facade模式显示不能直接访间实体 bean,而应开发会话bean,作为门户。如果能对实体bean增加一个本地接口,在同一容器中部 署两个EJB,则可以进一步提高性能 如果你不熟悉 Value Object与 Session Facade模式,则不容易理解上段的内容。别担心, 这些模式都将在本书稍后详细介绍。但可以注意,这两个模式都适用于某种情境。所有模式 都适用于某种情境,是一组矛盾的平衡。描述模式时,我们要明确定义所有这些项目。根据 前面提到的四位专家对设计模式的描述,模式具有四大要素 模式名,标识模式,增加表达性。 ·问题,描述何时应用这个模式,解释问题与情境 ·解,不描述具体设计与实现,而是描述模式模板,叮以在不同情境中使用。 ·结果,是采用一个模式的结果与取舍。结果对评估不同方法和进行决策至关重要。 设计模式描述如何在特定情境中解决一般设计问题。 计模式对常见设计结构的关键方面进行命名、抽象和标识。标识方案参与者,他们 的角色与责任及合作方式。大多数情况下,这些参与者是对象与组件。每个设计模式针对特 定问题。每个模式还描述其结果和取舍。 相关模式交织在一起,构成模式语言。模式语言不是正式语言,而是一组相关模式的 集合。模式和模式语言有助于更好、更快、更有效地学习、通信和解决问题。本书主要介绍 J2EE的模式语言,但介绍J2EE设计模式及其应用之前,先要介绍如何标识模式
第1*J2EE设计模式 标识模式 标识模式要靠经验。每个有经验的建筑师和设计人员能够看到,在大部分项目中会遇 到类似问题,这些问题的解也是相似的。当然,实际解不一定是相同的。但是,所有解具有 相同的基本概念。从抽象角度看,可以说所有这些解与问题表示具有共同抽象解的共同抽象 问题 了解这一点是标识模式的基础。我们应回顾过去的项目,标识处理过的问题。对每个 问题,应标识其特征,还应记录这些问题的解。然后收集类似问题与解,确定其相似性 类似解很可能表示一个模式。前面曾介绍过 Alexander的角门模式, Alexander通过大量 房间中门的布置位置找到这个模式。所有把门放在角上的房间都采用这种模式。前面介绍的 Value Object与 Session Facade模式也是这样,也是通过分析多个应用程序而得到的。 但是,一组解只有经过验证之后才能成为模式。由于 Alexander验证把门放在角上是有 用的,我们也要验证所找到的模式。在软件L程中验证复杂模式可能比验证角门模式之类的 简单建筑模式更复杂。 因此,我们不是直接标识模式,而是标识模式候选者。模式候选者是独立方案,i外 部的连接越少越好。记住,模式是为了复用。我们要验证模式候选者,通常使用三规则,即 每个模式候选者至少要在三个不同系统中证明之后才能成为真正的模式。这个规则不太精确 因此本书作者建议模式候选者应尽量多次验证,使模式更有实用价值 没有充分验证的模式可能带来大量危害。为什么呢?因为大多数建筑师、设计人员和 开发人员并不标识模式,可能没有时间,也可能没有这方面的经验。但他们通常都学习模式 和用其改进解决方案。无法达到目标的模式可能对大量应用程序造成伤害,从而给模式带来 不好的名声。 另一个重要问题是模式应采用哪一级抽象,包括多少实现细节。J2EE模式社区中普遍 接受的概念是模式应釆用高层抽象,但每个模式应包括解的细节。这些解的细节通常比模式 本身采用更低层抽象,称为策略。显然,模式与策略之间没有明显的分界。 由于本书介绍模式,因此会通过这些策略显示不同情境中如何采用模式。 在 Prentice Hall Ptr出版的《 Core j2 EE Patterns》一书(ISBN0-13064884-1)中 作者定义了模式与策略的下列差别 模式应采用更高层抽象,因此应提出最佳实现策略。 开发人员可以通过策略扩展使用模式,寻找实现模式的新方法。 ·模式与策略名称改进通信。 标识模式之后,要表示模式。下节介绍如何表示设计模式 表示设计模式 表示模式和定义模式一样难,仅仅靠统一建模语言(UML)之类的简单图形表示方法是 不够的。为了使模式真正促进复用,就要表示意图、动机、决策、后果,等等。要成功运用
实用]2EE设计模式编程指南 模式,就应提供具体例子 近年来,人们找到了多种模式。标识这些模式的作者将其发表到模式类别中。也诈最 重要的模式类别是前面提到的四位专家在设计模式中提供的23种模式。对J2EE开发人员,模 式类别是个社区过程,见JavaDeveloperConnection站点hp:java.sun.com。EE开发人员 的另一重要模式类别见htp/ww. The ServerSide. com/ 模式可以用正式与非正式方式表示。如今大多数模式类别用非正式方式表示模式。但 问题是他们不用相同格式,而采用稍有不同的格式。模式表示的主要差别源于不同类型模式 解决的设计问题并不相似。例如,前面提到的四位专家的模式解决面向对象设计问题,而核 心J2EE模式解决建立J2EE应用程序时遇到的问题 非正式方式表示模式时通常使用几段,有些是大多数表示中都有的,有些是不同的 大多数非正式方式表示基于前面提到的四位专家的著作中使用的表示。前面提到的四位专家 的著作中使用的表示采用下列模板: Pattern name and classification(模式名与类别) 每个模式应有惟一名称,使模式便于口头表达。 Intent(意图) 简要描述模式的作用、理由与意图、解决的设计向题 Also Known as(别名) 提供模式的别名名单。 Motivation(动机) 描述问题内容及如何用这个模式解决这个问题。 Applicability(适用性) 描述设计模式的适用情形,不好的设计例子及如何识别。 Structure(结构) 提供图形表示,可以使用UML图形。 Participants(参与者) 显示参与这个设计模式的类、对象和组件,及各处的责任。 Collaborations(协作) 描述参与者如何协作 Consequences(后果) 列出模式如何达到目标,使用模式的结果与取舍。 Implementation(实现) 实现模式的提示、技术与策略,以及特定语言问题和注意事项。 Sample code(样本代码) 显示如何实现模式样本代码 Known uses(已知用途) 实际系统中如何使用这个模式。 Related patterns(相关模式) 列出相关模式及主要差别
第1章J2EE设计模式 介绍本书提到的模式之前,先要简单介绍设计模式的好处及其如何帮助解决问题 设计模式如何帮助解决问题 了解模式之后,下面看看设计模式如何帮助解决问题。 设计模式可以帮助进行软件设计和更好地设计软件。 一般来说,设计模式可以帮助我们解决应用程序设计阶段遇到的大多数常见问题,包括: 标识 组件内部结构及组件之间的关系 确定组件粒度及适当交互 定义组件接口 J2EE平台设计模式解决使用J2EE服务与技术的常见设计问题,包括 请求处理 ·服务定位与激活 远程通信与层间通信 组件选择 持久状态、事务与安全性管理 ·EIS集成 设计模式还可以帮助我们进行设计: 更适合于复用 更壮实,便于今后修改 J2EE应用程序是由组件构成的,放在客户层、Web组件层和业务逻辑(EJB)层。Java 言开发的组件釆用面向对象方法。设计这类应用程序时,建筑师要面对不同问题:如何标 只组件、选择组件类型和标识组件的内部结构(如作为组件建筑块的对象)。确定正确的抽 象层、粒度与灵活性是很困难的,需要有足够的经验 这时软件开发方法不一定能帮上忙。尽管可以用不同方法标识与分析模型对象,但通 常不是显式针对设计模型组件与对象的。实际开发还显示,应用程序中的组作不一定直接模 拟实际对象,但分析模型中通常根据实际对象定义对象。 因此,要选择]2EE提供的适当组件类型并不容易,特别是在选择不明显时,有时还要 考虑性能与安全要求。Web组件也是这样,可能要选择JSP( Java Server Pages)或小服务 以及业务逻辑层组件,首先要选择不同类型的EJB(无状态会话、状态会话、实体和消息驱 动bean)以及选择 CORBA'iRMI-IIOP分布式对象和JMS。这个决策会产生长远的影响。 采用设计模式时,可以得到这些决策的准则。下面是设计模式的另一些好处: ·帮助我们进行适当抽象 ·帮助我们进行适当一般化 ·帮助我们确定攴持复用的适当粒度 ·帮助我们提高设计火活性,更妤地适应将来的改变