假期学习总结（一）

  

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

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

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 实例与对象

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

 

2、重构