分析模式读书心得之责任模式

分析模式读书心得之责任模式

Martin Fowler的《分析模式》买了许久，也看了很多遍，始终未能全部领会。这篇读书心得也只是疏浅的一点看法而已。

要说责任模式（Accountability）还需要先从组织架构的程序实现谈起。凡是一个项目，或多或少都要涉及到部门组织架构的描述。目前我们的解决方法无非就是两种：一种是需要递归的处理方式，另外是一种不需要递归的处理方式。

所谓需要递归的处理方式，就是每一个部门采用如下的数据结构存储：depart(dept_id,parent_id, ...)。这样的优点是可以表示无限的级别，缺点是处理速度慢，大部分都要用到递归。
所谓不需要递归的处理方式，就是每一个部门采用如下的数据结构存储：depart(levelcode, ...)。这里的levelcode是一种具有层次关系的数据结构，比如字符串方式：company.software.development.java_team，或者类似邮政编码的方式0105080905。这样的优点是处理速度快，直观，通常不需要递归，缺点是表达受到存储容量的限制（比如字段长度等等）。

为了表达的需要，我们以下例子都采用需要递归的结构来表达。

现在就提出问题了，很多时候部门结构并不是单一的，参考常用的矩阵式项目组织结构，一个项目组既需要向公司的项目管理机构负责，也需要向所在的部门负责，这种结构我们如何来表示？

一般来说，如果世界只是这么简单的话，我们毫无疑问可以把刚才的部门定义修改成这样：project(proj_id, dept_id, proj_mgr_id, ...)。事实上程序分析设计人员要面临的世界很复杂，如果需求中公司的CEO准备直属领导该项目的时候怎么办？所以我们需要寻找一种更有效和更简单的表示方法，来适应这种多个层次结构体系同时并存的情况。

《分析模式》把部门、项目、公司甚至于个人都笼统地概括为“组织(Organization)”。通过使用一个中间对象（表）替代我们上述的直接id关联，就可以支持多个层次同时并存的情况。它给出的定义是这样的：

class Organization

class OrganizationStruct

class TimeLimit

但是这样的结构虽然灵活性够高，但是约束性不够。因为用以上的结构，我们同样可以把“项目”描述为“公司”的上级部门了。那么如何增加这种结构的约束性呢？很简单，把OrganizationStructType从一个简单的enum定义成一个实体就可以了：

class OrganizationStructTypeEntity
class Party

class Accountability

class TimeLimit

责任类型模式的应用面当然比单纯的“组织结构”要广泛的多。更重要的是，我们程序的复杂度并没有增加。这里摘抄书本中的两个例子：
John Smith为某公司工作，这里可以被建模为一个责任类型，其中某公司是委托方，John Smith是责任方，责任类型是雇佣关系。
John Smith允许Mark医生作内窥镜检查，这里可以被建模为一个患者许可类型的责任模型，其中Mark医生对John Smith负责。

但是，责任依然给模型带来了复杂性，因为责任类型显然要比组织结构类型要多得多。这个将带来我们应用上的麻烦：我们要为新的责任类型编制规则--每个责任类型都要一个规则！如果这个要放到数据库中去，可就麻烦了。

所以我们还需要改进这个模式，就是要把这些约束相关的数据抽取出来，和具体的算法独立开来。《分析模式》告诫我们一个建模的原则：“把模型清晰地分解成操作级和知识级”。这里的“知识级”很多人也称之为“元模型”，但是Martin说明了他不用“元模型”来称呼“知识级”的原因。

知识级的代码描述如下：

class AccountabilityType

class PartyType

操作级的代码描述如下：

class Accountability

class Party

一旦有了知识级的描述之后，我们很容易用外部的代码来验证其中的约束关系：
所有的 Party.Comissioners 必须隶属于 PartyType.Comissioners。
所有的 Party.Responsibles 必须隶属于 PartyType.Responsibles。

有了“知识级”的概念之后，我们的“责任类型”又可以保存到数据库中去了。当然，做这样的划分目的并不只是为了能够放到数据库中哦。

我们还继续要对“责任模式”进行改进，因为我们遇到了新问题：小王是一个项目经理，同时因为常见的原因又兼任项目的系统分析员。使用以上的模型，我们可以把小王看作是项目经理，也可以看作是系统分析员，但是不能两者都是。当然我们有很多的折衷办法来处理面前的这种情况，也可以采用《分析模式》给我们的解决方法：让团体类型可以相互继承。这样我们就可以创建一个“项目经理兼分析员”的团体类型了。修改之后的代码如下：

class PartyType
class AbstractAccountabilityType

class PartyType

class Accountability

class Party

class LevelAccountabilityType // 分层的责任类型

class HierarchicalAccountabilityType

这里没有描述书本中图2.13“反复权衡责任类型的子类型”，因为看书看来看去，没有找到什么“定向的责任类型”的说明，而且四处找不到可用的英文版的文档下载，谁可以提供一下，万分感谢。

最后，在责任模式的操作范围定义中，提出了责任模式可以引入“职位”的概念，所有的职责可以和职位关联，然后个人再和职位做一个“雇佣”的责任模型，不过书中建议除非职位变化很快，否则就不要再引入太多了。