GRASP Creator Pattern - GRASP之创建者模式

问题

类的实例的创建职责，应该分配给什么样的类？或者说类的实例应该由谁创建？

Creator模式所提倡的解决方案

以下条件之一为真的情况，类A的实例的创建职责就分配给类B。
1，B包含A
2，B聚集A
3，B记录A
4，B频繁使用A
5，B有A初始化数据
Creator模式提倡类的实例（对象）创建职责由聚集或包含该对象的对象创建。

注：Creator模式只是一个原则，如果类A，B之间没有包含或聚集关系，应该先考案是否有“B记录A”，或者“B有A初始化数据”的关系，然后是“B频繁使用A”的关系。另外，作为代替方案，一般的采用工厂（Factory）创建方案。

如果不遵循Creator模式，把类的实例的创建职责交给无关的类，类之间的关系变得复杂化，降低系统的可维护性和可扩展性。

一般来说，应用Creator模式，可以从上之下设计好类之间的包含或聚集关系阶层图，让每个类负责创建自己包含的类的实例。

应用Creator模式的好处

- 整个结构清晰易懂
- 有利于类或组件的重用
- 防止职责的分散
- 降低耦合性

为了更清楚地说明Creator模式，我们举一个GUI的例子：
有一个用户窗口MainWindow，包含Menu，ToolBar，Dialog等，Dialog上布置有Textbox，Button等元素。
我们应用Creator模式，先为它们设计好具有阶层关系的类图，如下：

因为MyMenu，MyToolBar，MyDialog由MainWindow所包含，MyTextbox，MyButton被MyDialog包含，MainWindow由Main类调用，
根据Creator模式所提倡的方法，它们的实例的创建职责的分配应该是：
MainWindow的实例由Main创建
MyMenu，MyToolbar，MyDialog的实例由MainWindow创建，
MyTextbox，MyButton的实例由MyDialog创建。

反过来，如果MyMenu，MyToolBar，MyDialog等实例的创建都放在Main类里，那么Main就跟它们产生一种“关联”关系，如果MyMenu，MyToolBar，MyDialog等发生修改，Main也不得不跟着一起修改，也就是说大大增强了Main类跟它们之间的耦合关系；而Main类本身，也聚集了多余的实例创建功能，降低了Main类的聚合性。