一个对象撕心裂肺的怒吼：谁来创建我！ GRAPS（4）创建者模式

 

当我们分析清楚客户需求设计出用例模型以后，当我们分析清楚客户的业务环境制作出领域模型以后，当我们综合用例模型、领域模型和我们的聪明才智设计出一个又一个的类和它们各自的方法以后，当就在一切都准备就绪只欠东风的关键时刻，一个对象发出了撕心裂肺的怒吼——谁来创建我？！！！一个对象，不管拥有多么强大的功能，不管进行了多么精巧的设计，如果不能被创建，就如同韩信不能做将军，孙膑不能当军师，勾践不能回越国，刘备不能得荆州，一切一切的雄才武略都如废纸一张。既然“创建”对于对象如此重要，我们就来好好探讨一下GRASP中关于对象创建的问题。

3.创建者（Creator）

当我们完成了用例模型、领域模型、对象分析的设计，初步完成了对象设计和职责分配的工作，开始进一步细化的时候，一个我们不得不考虑的问题就摆在我们的面前——谁来创建这些对象？也许现在的你会觉得好笑，这也是问题吗？在软件实际开发过程中，谁需要使用某个对象，就去创建它就行了，有什么好讨论的。但是，我不得不说的是，如果你只是漫不经心地想要随意开发一套软件系统，仅仅是完成自己工作而已，你完全不用考虑创建对象的问题。然而如果你希望开发一套高质量的、低耦合的、封装性和复用性高的软件系统，你必须得认真考虑这个问题。为什么呢？因为系统中如果一个对象A创建另一个对象B，那么对象A就必将与对象B耦合，这个我已经在前面《（原创）一个优秀的软件开发人员的必修课：GRASP（2）低耦合》中提到。我们可以想像，如果在你的系统中，对于对象B，你也去创建，我也去创建，大家都去创建，对象B势必与许多对象发生耦合，耦合度将大大提高；但如果对象B可以都由对象A来创建，然后由对象A向其它需要对象B的对象提供对象B，即其它对象需要使用对象B的时候都向对象A索要，那么整个系统对对象B的耦合将会大大降低，同时对象A和B也可以形成一个封装的、可复用的独立系统，则这个软件系统的设计质量势必提高。所以，对象创建的问题不可不察。

那么为了降低系统耦合，提高系统的清晰度、封装性和可复用性，应该有一些通用的原则，以用于对象职责分配中，关于“创建对象”这类职责的分配。这些原则的描述就在GRASP的“创建者”模式中。

1）创建者模式的描述

如果以下条件之一为真（越多越好），则将创建类A的实例的职责分配给类B（B是对象A的创建者）：

1．B包含或组成聚集A。

2．B记录A。

3．B直接使用A。

4．B具有A的初始化数据，并且在创建A时会将这些数据传递给A。因此对于A的创建而言，B是信息专家（关于“信息专家”模式我会在后面描述）。

如果有以上多个选项适用，通常首先条件1（B包含或组成聚集A）。

 

2）何时使用

在理解创建者模式的时候，我认为一个首先必须理解的问题是，在软件项目的整个过程中，它应该是在什么阶段使用。一个网友曾经发帖问我，他不清楚GRASP一般适应于软件开发的什么阶段。我认为，GRASP作为职责驱动的基本原则，一般适用于对象分析和设计的中前期。在软件项目的前期，也就是需求分析阶段，我们通常是制作用例模型和领域模型。用例模型往往描述的是用户对整个项目提出的所有功能的集合。对于每个功能，我们通常使用用例，并在用例描述中描述该用例的主要流程。因此用例模型描述的通常是需求分析中动态的部分。领域模型往往描述的是用户提出的整个问题空间中的各种事物及它们的相互关系，因此领域模型描述的是需求分析中静态部分。领域模型虽然不是完全，但却是以此为基础，形成软件系统中的软件类。为什么不是“完全”呢？因为软件系统中需要什么类，是软件系统功能的要求。假如在领域模型中的某个对象，它的确是用户问题空间中的事物，但是它在软件系统功能的要求中使用不到它，那么在软件系统中它同样不能成为一个软件类。当我们设计好了软件类以后，我们就将根据用例模型，为所有的软件类分配职责，确定它们各自应具有的行为及相互的协作。每个软件类应当如何分配它们的职责，也就是说用例模型中描述的各个功能应当交给哪个或哪些软件类去实现，这个工作就是对软件类的职责分配。完成这个工作的阶段主要在对象分析的中前期，也正是我们大量运用GRASP的时期。职责分配需要一定的原则，这个原则将是GRASP“信息专家”模式将要讨论的内容。当我们将一个一个的软件类的职责分配好了，其各自的行为和属性也确定下来了，下一步需要考虑的问题就是它们应当在何时，由谁来创建。解决对象创建问题当然应当交给创建者模式来完成。因此不难理解，创建者模式应当运用在对象分析中前期稍靠后一点儿的阶段，即软件类的主要职责及其行为都设计好了，讨论该何时，由谁来创建它的时候。

3）为什么

我们做事往往有个习惯，凡事问个为什么。前面我提到，使用创建者模式的主要目的是可以降低系统的耦合。那么，我们在使用创建者模式的这几个建议的时候是如何降低耦合的呢？这一直是困扰了我很久的一个疑问，Craig Larman对于这一点没有清楚地描述。但是，我们接受一个新事物，如果都没有弄清楚为什么就盲目接受，这是一种十分不严谨的态度。我现在通过我在项目中的一些实践和自己的一点儿愚悟，谈谈自己的看法。

创建者模式告诉我们，如果系统中存在包含者容纳被包含者，或整体聚集部分，则包含者往往是被包含者的最佳创建者，整体往往是部分的最佳创建者。为什么呢？首先，这样的设计易于理解，可读性强。为什么这么说呢，我们用我们常见的单据与单据明细来说明吧。一张单据有多条单据明细，这些单据明细聚集于单据中，是单据的一个部分。对于某张单据，我们只有去填写这张单据，才会去填写它的明细。同样，我们要查看和修改这张单据的明细，首先肯定是找到这张单据。以上这些是我们在实际生活中大家都认同的管理单据的方式。GRASP所提倡的一个十分重要观念就是低表示差异，也就是说实际生活中是怎样的，我们就怎样设计。用更加专业点儿的术语表述为：软件设计应当与用户的问题空间保持低表示差异。正因为如此，我的软件设计中，一个单据对象存在了，它的单据明细对象才可以存在；要得到一个单据明细对象，应当先找到它所在的单据对象。既然单据对象与单据明细对象是如此的逻辑关系，我们假设单据明细对象不是由单据对象创建，而是另一个对象X，那么对象X即要创建单据对象，又要创建单据明细对象，还要维持单据对象与单据明细对象的聚集关系。这样的设计不难看出，代码实现比较复杂，可读性差。不仅如此，其耦合度也必然增加。对象X与单据对象和单据明细对象都需要耦合，单据对象与单据明细对象之间同样需要耦合。如果修改一下设计，对象X创建单据对象，而单据对象去创建单据明细对象，则对象X只与单据对象耦合，单据对象再与单据明细对象耦合，耦合度就降低了。所以，包含者创建被包含者，整体创建部分可以有效降低耦合。同时，这样的设计，单据明细对象的创建只与单据对象有关，整个系统都由单据对象向其它对象提供单据明细对象，那么单据对象与单据明细对象则可以比较容易地形成一个关于单据的独立系统。这样一个独立系统可以比较便利地应用到其它需要使用单据的地方，其可移植性也就提高了。

尽管包含者往往是被包含者的最佳创建者，整体往往是部分的最佳创建者，但是在一个软件系统中，并不是所有类都有它的包含者或者整体。如果没有，谁应当创建它呢？记录者当然是另一个可以考虑的人选。仓库管理员管理进出库是ERP系统一个非常重要模块。在实际生活中，一批产品存入仓库，仓库管理员当然是需要填写入库单。这个入库单在仓库管理员填写之前，本没有，是仓库管理员填写之后才有，我们是不是可以说仓库管理员创建了一个入库单。既然现实生活中如此，我们在软件设计中是不是也应该由仓库管理员对象负责创建入库单对象，符合低表示差异，不言而喻也符合低耦合。同样，在这个软件系统中仓库管理员填写入库单，在其它的系统中也同样是仓库管理员填写入库单。仓库管理员与入库单这对封装的独立体也同样可以应用到别的系统，可移植性和封装性也得以提高。因此记录者创建记录内容也是我们可以考虑的一个方案。

如果我们正在设计的软件类也没有记录者，这可如何是好？具有创建这个类所需数据的那个类可以考虑，那个类就是信息专家（什么是“信息专家”，我会在以后对信息专家模式的文章中详细描述）。在我们的设计过程中，很多类的创建是需要一些初始化数据的。最典型的就是我们的vo（值对象）。在java程序中，vo往往是用来传输数据的，也就是说创建vo的初始化数据就是这些它需要传递的数据。如果这些数据在某个Action中，创建vo的当然就是这个Action。而如果这个vo的初始化数据来自BUS，则该vo的创建当然应当是这个BUS中。

如果以上方法还不行，那我们就只有找使用者了。寻找使用者是我们创建类最常用的一种方法，但它的缺点也非常明显。正如前面我描述的，我们系统中对某个软件类的使用可能分布到系统的各个角落。当我们因为某个需求需要修改这个类的时候，我们根本不知道谁在使用它。正因为如此，这样的修改变得如梦魇一般，不断地搜索，不断地修改。我们前面说过，合理的软件构造是为了使我们的变更代价最小，而这样的变更将使我们的代价太大了，也许一个不经意的变更错误将造成我们的系统中一个意想不到的地方发生异常。故我们变更后测试的代价也就因此而增大。总之，寻找使用者作为创建者是我们业务分析阶段最后的终极选择。

4）创建者模式是原则，不是准则

“创建者模式是原则，不是准则”难道“原则”和“准则”还有不同吗？当然。创建者模式是原则，所以我们在业务分析阶段应当尽量遵守。但创建者模式不是准则，因为并非我们的所有软件类都必须遵守。为什么这么说呢？随着项目的进行，我们的分析设计就不再停留在业务的分析上，各种具体的框架和技术将不断引进项目中，这时对象的创建就不一定符合创建者模式。比如，为了提高系统的性能和可维护性、更好地处理对象的创建与回收等复杂的问题，我们常常把对象的创建交给工厂，如spring的beanFactory、hibernate的sessionFactory等等。“工厂”不论是“具体工厂”还是“抽象工厂”，都不符合创建者模式中的任何一个条件。为什么呢？因为创建者模式中的各个条件都是来自对领域模型和设计模型的分析，说得更加直白一点儿就是对客户现实世界的分析，与技术无关。在技术领域的对象分析和设计已经超出了创建者模式适用的范围，这更多的是出现在对象分析和设计的中后期。所以，正如我前面所述的，创建者模式适用的时期，是对象分析和设计的中前期，对象的业务分析稍晚一点儿的阶段。

 

总之，合理地创建对象可以有效的提供可读性、降低耦合度、提高系统的封装性和可移植性，我们应当引起重视。