马上就要回北京，两个月的假期就这样转瞬即逝了，一边修养生息，一边学习新东西，因为要兼顾修养，因此没有很固定的时间很有计划的学习，本来可以就很多学习内容做些总结，也可以做一些学习笔记。但始终也没有时间来做这些，因为就某一专题具体论述，都要经过细推敲，于是把一些要点总结一下。

假期主要阅读了下面这些书，由于每本书都很有难度，所以每本都只读了一半，而且发现看一本书时忽然需要另一本书的概念支持，所以又看看别的书：

1 、 Refactoring 重构， Martin Fowler

2 、 Design 设计模式。 GoF

3 、 UML 与模式应用 Apply UML and Patterns ， Craig Larman

4 、 Pro Spring （在书店看了前两章）

下面这本看了三遍，而且很多主题经过了反复的研究并进行了实验

5 、 Spring 从入门到精通，郭峰

下面这本看了两章，但是做了实验

6 、精通 SOA ：基于服务总线的 Struts+EJB+Web Service 整合应用开发，梁爱虎

 

1 、面向对象关键词

1.1 领域模型（Domain Model）

领域模型 是对①领域内的概念类或②现实世界中的对象的可视化表示。 [MO95 ， Fowler96]

 

1.1.1 领域模型是个多义词

在 UP （更广泛而言，在 OOA 中）领域模型指的是上面的概念，也就是说它是现实世界中对象的概念透视图，而非软件透视图 (Larman 《 Apply UML and Patterns 》 ) 。 对于上面概念的详细解释如下，它是对于某个领域（比如医药、保险、生产制造等）中的概念类（也就是平常所说的那些抽象概念，如思想、事物或对象。比如销售、订货、指令、商品（在销售领域叫商品，在生产制造领域就叫产品，在流通领域叫货品，它们都是抽象概念，这点与苹果等实际的事物是有区别的）等，它们不是现实世界的东西，而是人们创造的非实物的想出来的东西。）或现实世界中的对象（比如汽车、苹果）的可视化表示（通常就是用图形进行表示）。也就是领域模型的概念由两要素组成：表示的是什么（①领域内的概念类或②现实世界中的对象）和怎么表示（可视化表示）。我们需要注意领域模型的讨论语义来讨论它。比如在进行 OOA 时，只需要和领域专家（更广泛的讲，接受你调查的需求提供者都应该算作领域专家）进行沟通从纯业务的角度来考虑该模型，而不应该掺杂进软件的思想。 在这个阶段，我们创造的是现实世界或领域内的模型，领域之外或现实世界之外的就不要涉及。

 

领域模型的另一个语义则是跟软件有关了。它指的是 软件对象的领域层 ，在表示层或 UI 层之下的 软件对象层 是由领域对象组成的——领域对象是表示问题领域空间事物的软件对象，并且与“业务逻辑”或“领域逻辑”方法相关。例如，软件类 Board 具有 getSquare 方法。 (Larman 《 Apply UML and Patterns 》 ) 。 为避免误会，在这本书里， Larman 把该语义下的领域模型称为领域层（ Domain Layer ）。对象具有属性和方法，这一点在现实世界或领域内和在软件语义中是相同的。

 

1.1.2 几个概念的区别

1.1.2 .1 、领域模型与数据模型

   Larman《 Apply UML and Patterns》：

领域模型不是数据模型 （通过对数据模型的定义来表示存储于某处的持久性数据），所以在领域模型中，并不会排除需求中没有明确要求记录其相关信息的类（这是对关系数据库进行数据建模的标准，但与领域建模无关），也不会排除没有属性的概念类。例如没有属性的概念类是合法的，或者在领域内充当纯行为角色而不是信息角色的概念类也是有效的。

从直观感觉来说，数据模型是指包含数据和数据关系的模型，而领域模型是可以不包含数据的模型。从作用上来讲，它们也是完全不同的，领域模型是用来表述领域的概念或现实中的事物的，这些事物或概念不一定要持久化，而数据模型描述的都是需要持久化的数据。

从第二点区别来讲的话，就出现两种开始设计软件的方法：面向对象和面向数据。长久以来，我们（指的是笔者和笔者所在的团队以及周围的团队）都是采用面向数据的方法开始，也就是先从画 E-R 图、设计数据库结构开始，然后再设计类层次结构，其实这也是没有办法的，在学校就是这么学的，也没有人讲过怎么从面向对象开始。而且由于数据库不是面向对象的，而我们做信息系统的很重要一点是要将数据保存到数据库。

Apply UML and Patterns 这本书真是堪称经典， Larman 将相关概念讲的十分通透，而且全书采用两个例子来传授敏捷 UP 的实践过程，并且旁征博引，让我受益匪浅。这个假期很多知识和思考都来自 Larman 这部著作。

 

1.1.2 .2 、领域模型与设计模型

在这里我们讨论的领域模型都是第一个语义下的领域模型，因此它与设计模型的最大区别是一个是面向领域的，一个是软件的。而领域模型的第二个概念，则主要强调了软件的领域对象层，这与设计模型也是不完全相同的。对于后一种区别似乎不是很清晰，它们的区别应该着眼于讨论范围的不同。设计模型应该是个更宏观的概念，而领域层是特指在多层体系结构中的一层（然而在我们现在接触的很多项目自然就被设计成多层结构的，因此大多数情况下可能体会不到其区别）。

设计模型可以从领域模型（第一个语义）推倒出来，你可以在 Spring 的 Sample 中看到给出的例子含有 model 文件夹，里面包含了重要的领域模型（第二个语义，可以看作是设计模型的一部分）。因为并不是所有的类都是领域层，还有其他的类从其他设计模型转化而来。

 

1.1.2 .3 、领域模型与领域规则（业务规则）

领域规则 [Ross97 ， GK00] 指出领域或业务是如何运作的。领域规则通常被称作业务规则，然而两者是前者包含后者，后者是前者的子集的关系。在领域建模阶段，我们会通过捕捉领域规则来捕获凌驾于特定应用之上的长期规则或政策，例如税法。（ Larman 《 Apply UML and Patterns 》 ） 某些领域模型描述了领域规则，很多领域模型中还有领域规则。

在分层结构中，领域层和业务规则层往往是对应的，比如在 Brown 分层模型、 Marinescu 分层模型中的领域层跟 Core J2EE 分层模型、 DNA 分层模型中的业务层（业务规则层）是对应的。在叫法上斤斤计较是没有意义的，在这里提一下主要是想明确一下各种概念的区别和联系。

 

1.1.2 .4 、领域模型（领域层）与 MVC 中的 Model

在《设计模式》中，对 MVC 有如下描述：在 Smalltalk-80 中，类的模型 / 视图 / 控制器（ Model/View/Controller ）三元组（ MVC ）被用来构建用户界面。……模型 Model 是应用对象，视图 View 是它在屏幕上的表示，控制器 Controller 定义用户界面对用户输入的响应方式。在《 J2EE 核心模式》中又详细地讲解了 Model I 和 Model II ，很多书中也都将 MVC 称为表现层模式。那么这里面的 Model 是不是就是领域模型（领域层）呢？看上去好像就是这么回事。等有时间我再好好研究一下 MVC ，就可以解答这个问题了。

 

1.1.2 .5 、领域模型（层）与常见 Object

VO （ Value Object 或 View Object ）

这两个 VO 是怎么回事我没仔细研究过，最早见到 VO 好像是在 Core J2EE Patterns 里，我的理解是 VO 就是个哑对象， Struts 中的 Form Bean 就是 VO ，它不是 Model ，不过在《 Spring 从入门到精通》（郭锋著）将 VO 当成领域模型，在 SpringFramework 的例子里，相似的代码放在 domain 目录下，所以我觉得 VO 可能就是个用来传递数据的，而不是像在《 Spring 从入门精通》中那样，当成 domain 。两套程序都含有 service 目录，但作用却不同，在《 Spring 从入门到精通》中它是用来封装业务逻辑的，而在 springframework 里 jpetstore 中， service 是来封装远程服务的，而在 domain 目录下的 logic 目录里的文件是来封装领域规则的。从前面论述的结果来看，我觉得还是 springframework 例子里的结构比较合理（大师级的作品，经过全世界无数大师的验证，而且 Rod Johnson 也是敏捷爱好者，不会犯这种错误的）。关于 VO 的具体作用，我还是回去重新看看 Core J2EE Patterns 再下结论吧。

还有以前我和很多初学者很疑惑的问题，什么 TO ， PO 都是干什么的？后来也是看了 Core J2EE Patterns 才知道， TO 是传输对象，主要是用来在 DAO 层和 BLO 层传递数据的，而 PO 是持久化对象，主要是用来与数据库表进行一一映射的。这都属于设计模式，但是往往被人滥用，不加分别的在同一语境下讨论 DM （ Domain Model ）， VO ， TO ， POJO ， JDO ，造成了初学者的混淆。我觉得 VO 和 PO 分别被包含在了表现层框架和持久层框架中了，表现层框架中那些 FormBean 就应该是 VO ，而 Hibernate 中所谓的那些 POJO ，就是 PO 了，而在各个层次中传递数据的对象都可以称为 TO 了（更广泛的来讲）。

1.2 用例

    用例是图形，不是文本。（ P46 ）

用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。（ P47 ）

用例就是需求，主要是说明系统如何工作的功能性或行为性需求。（ P48 ）

用例是一种优秀的方法，使领域专家或需求提供者自己编写（或参与编写）用例成为可能，并使这项工作难度降低。用例的另一个价值是强调了用户的目标和观点。（ P48 ）

我们经常发现，用例建模新手（或具有严重 A 型行为的分析员）过于关心那些次要的问题，比如用例图、用例关系、用例包等，而不是致力于简单的编写文本情节的实际工作中。 （ P48 ）

                            —— Larman 《 UML 和模式应用（原书第 3 版）》（机工）

第一次看到 Larman 的这些话，我仿佛找到了一个出口，因为以前进行系统分析时，总觉得用例图往往只是个摆设，因为它所能涵盖的内容太少了，操作契约、条件分支（在 UP 中叫扩展，那时候不知道有什么主成功场景的说法，然后自己想当然的像画业务流程图一样分出好多枝杈，其实每个有必要说明的“枝杈”都应该在有必要的情况下画一个用例图），虽然原来知道有用例文本一说（那时统而言之叫做用例说明），但常常以为那只是起补充作用的次要部分。然而看了 Larman 的讲解后，才知道那些才是关键。正如上面引述的最后一段话所言，那的确是这两类人最容易犯的错误，我就是，过于关注用例图而非实用的文本信息。（不过这也不能怪我，因为当时学习面向对象时，用例 = 用例图），还记得那时在一个需求提供者面前用 Visio 画用例图记录她的需求的场面，她显然是看不懂，而在我看来当时那些不过是糊弄外行的画儿而已，实际作用甚微。其实书看到这我还是有很多疑问的，比如用例到底怎么写，包含哪些要素，何时写和写到何种详细程度（因为 UP 中典型的初始、细化、构造、移交阶段对于用例的详细程度是不同的，其实在敏捷 UP 中，只有一个原则——够用就好 ~ ）。

下面也是从该书中摘录出来的一些内容，以备他考。

1.2.1 用例三要素

Larman 在书中并没有给出这样的说法，但我觉得它们组成了用例的核心部分，它们分别是参与者、场景和用例。

参与者 就是具有行为的事物，可以是人，计算机系统或组织。

场景 就是参与者和系统之间一系列特定的活动和交互。

用例 就是一组相关的成功（主成功场景和其它扩展（替换场景））和失败场景的集合。

1.2.2 用例参与者

      参与者是任何具有行为的事物， 在所讨论系统（ System under Discussion ， SuD ）调用其它系统服务时，还包括其自身。

      参与者三种类型：主要参与者，协助参与者，幕后参与者。

       主要参与者 ：具有用户目标，并通过使用 SuD 的服务完成。例如收银员。

      协助参与者 ：为 SuD 提供服务（例如信息服务）。自动付费授权服务即是一类。

      幕后参与者 ：在用例行为中具有影响或利益，但不是主要或协助参与者。如政府税收机构。

1.2.3 三种常用形式

     它们被应用在不同的 UP 阶段。

     在初始阶段， UP 中提出给出大多数用例的简单描述，指的就是这种形式，叫做摘要。它只记录主成功场景。而非正式用例也出现在这一阶段，区别在于它是不同场景的组合描述。

     在初始阶段提到的对 10% 需求编写详细用例就是指的详述用例，它包含所有必要细节。

1.2.4 [ 详述用例 [ 模板

用例的不同部分	注释
用例名称	以动词开始
范围	要设计的系统
级别	“用户目标”或“子功能”
主要参与者	调用系统，使之交付服务
涉众及其关注点	关注该用例的人，及其需求
前置条件	值得告知读者的，开始前必须为真的条件
成功保证	值得告知读者的，成功完成必须满足的条件
主成功场景	典型的、无条件的、理想方式的主成功场景
扩展	成功或失败的替代场景
特殊需求	相关的非功能性需求
技术和数据变元表	不同的 I/O 方法和数据格式
发生频率	影响对实现的调查、测试和时间安排
杂项	例如未决问题

   

   这张列表里为我解除对用例最大疑惑的就是主成功场景和扩展（替换场景）的出现。它解决了我过去对于在用例中出现条件分支时手足无措的棘手问题。另外前置条件和成功保证（后置条件）也是相当有用的。我觉得成功保证不是一个好的术语，它的基本意思其实是如果系统成功运转了，会产生什么样的结果——如果看到这些结果同时出现，则保证成功了（估计成功保证这一术语就是这么来的）。

 

Larman 这本书传递的一个重要思想就是在必要的时候做必要的事，而且有有效果有价值，反映用户目标和价值。与现在整个软件业讲求实用的主流是一致的，正如敏捷宣言所说的那样，简单、有效才是最正确的。这种获益的感觉在读 Rod Johnson 的三部连续的巨著时也产生过，那是第一次听到循证这个词时，让我感到了一种特别的归属感。我就是一个讲究实用的人，而且喜欢速效的人——后来看 Martin Fowler 的书和文章，发现他大抵也是这么一个人。

Larman 的这本书目前刚看到第 12 章：从需求到设计——迭代进化。其中“以迭代方式做正确的事，正确的做事”让我想起来当初学管理学时所讲的经典言论——做正确的事比正确的做事更加重要。这本书一个 40 章，而且有太多东西需要思考和实践，因此看完此书估计还得有一阵子了。

1.3 类关系

继承（ Inheritance ）： 记得好像是在 Rod Johnson 的书里将继承分为两类，一种是接口继承，一种是实现继承。我愿意从它们的两个关键词来理解它们，接口继承使用 Implement 。实现继承使用 Extends ，他们正好表现其含义，一个是实现接口，一个是扩展父类。比较提倡使用接口继承——因为提倡面向接口编程——这个应该是业界的共识。

关联（ Association ）： 指的是类（更精确地说，是这些类的实例）之间的关系，表示有意义和值得关注的连接。在 UML 中，关联被定义为“两个或多个类元之间的语义联系，涉及这些类元实例之间的连接。”关联有点像关系数据库中的“联系”。

1.4 依赖与依赖注入

跑去书店看了看孙卫琴写的《 Java 面向对象编程》，才终于理解了“依赖”这一术语的含义（可能以前也看过，不过没有留意）。依赖指的是类（更准确说应该是对象）之间的调用关系，在 A 类中创建了 B 类的实例 b ，然后调用了 b 的方法，就叫 A 依赖 B 。

     明白了什么是依赖，才知道了什么是依赖注入。所谓注入，指的是使用 XML 将被依赖的类注入到需要依赖的类。比如 Spring 中，在 A 类中声明一个 B 的实例，产生 setter ，然后在 xml 文件里一配置，就完成注入了。

 

1.5 实例与对象

不记得哪本书上写的了，最近刚看到的，很明确的给出了实例和对象的关系——对象是类的实例。（在很多书里经常一会对象一会实例的，而且还是在相同语境下，把我彻底搞懵了。）

 

明天接着写下一部分：重构和设计模式