纯虚构模式（Pure Fabrication）是GRASP扩展模式之一，它把非问题领域中的职责分配给人工定义的类。

问题：

非问题领域中的职责应该分配给谁？或者说，按照信息专家等模式分配职责时，存在某些不恰当的职责时，应该怎么做？

所谓不恰当的职责，是指难以分配的职责：在保证高内聚，低耦合的条件下，某些职责难以分配给现存的任何问题领域里的类。

Pure Fabrication模式所提倡的解决方案：

Pure Fabrication模式提倡把那些非问题领域的职责分配给那些人工生成的或者容易此类职责的概念类。

Domain Class的概念

我们设计对象的时候应该尽量保持与现实世界里的对象一致。这种与现实世界里的对象保持一致的从业务分析中抽象出来的类叫做“Domain Class”。它相当于上述问题领域里的类。

比如一个简单的用例：用户注册。

用户就是一个“Domain Class”，它是现实世界里的业务对象。相当于这里的“问题领域里的类”。

用户注册需要操作数据库，[数据库操作]是系统功能实现的一个必需功能，它不是现实世界里存在的业务对象，它是一个非Domain Class。如果把[数据库操作]看作一个行为职责，它就相当于这里所说的“非问题领域里的职责”。

一般来说，Domain Class与非Domain Class的功能如果聚集在一个类里，就破坏了“高内聚”原则。

应用Pure Fabrication模式的好处：

1. 高内聚。不必分配问题领域以外的职责给各Domain类，从而保证各Domain类内部功能上的高度聚集性。
2. 低耦合。问题领域以外的职责被分配给第三方非Domain类，一方面可以降低各Domain类之间的关联程度，另一方面可以比较漂亮地整合系统的各方面的职责。
3. 重用性。各Domain类由于功能上的聚集与关联度的降低，可以更容易地得到重用。

Pure Fabrication模式的应用例

以上述“用户注册”的用例为例，对于问题领域里的类“用户（User）”，如果把“数据库操作的职责”分配给“用户（User）”，那么User类的内聚性大大降低。

应用Pure Fabrication模式，应该人工定义一个数据库管理的概念类UserDbr，把数据库操作的功能分配给它完成。

如图：

如图，分离Domain类User与非Domain类UserDbMgr，User类只保持问题领域中的信息。保证了高内聚性，和易重用性。