因为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类的聚合性。
GRASP High Cohesion Pattern - GRASP之高内聚模式
高内聚模式（High Cohesion）是GRASP模式中为降低类的复杂程度，简化控制而提出的面向对象设计的原则性模式。高内聚（High Cohesion）与低耦合（Low Coupling）模式是GRASP其他模式的根本。
问题
怎么做才能降低类的复杂程度，简化控制？
High Cohesion模式所提倡的解决方案
紧密相关的功能（职责）应该分配给同一个类。
所谓内聚，是指单个物体（类）内部的功能聚集度。比如，只包含有相互关联的功能的类，具有高内聚性，同时，它的外部表现（作用，意图）也就明显；反之，如果一个类由一些不相关的功能构成，它的内聚性就低，它的外部表现就不明显，一方面很难理解它的作用和意图，另一方面，一旦需求变化,扩展性就差。
在现实世界里，高内聚（High Cohesion）表现在“各司其职”上，也就是说自己只干跟自己相关的工作，别人的工作让别人做。比如，电视机只有信息传播的功能，冰箱只有冷藏冷冻的功能，它们就是一个功能高内聚的个体。为什么不把电视机与冰箱的功能做在一起呢？因为做在一起的话，一方面，只需要电视或冰箱功能的消费者却不得不同时购买它们的整合体，而且消费者如果想换代电视机时，冰箱也只有一起换代；另一方面，如果厂家需要升级电视功能，也不得不考虑怎么整合原来的冰箱功能。也就是说功能低内聚的产品，不利于消费者使用，不利于生产者维护，不利于产品本身的升级换代。
同样，反映到软件设计上，低内聚的类存在使用难，维护升级难的缺点。
高内聚（High Cohesion）与低耦合（Low Coupling）是GRASP模式的核心概念，是其它GRASP模式的根本。
优秀的面向对象设计，一般都遵从[高内聚，低耦合]原则。
应用High Cohesion模式的好处
- -
聚集相关功能，结构清晰，容易理解
只聚集相关功能，使得类的职责单一明确，从而降低类的复杂程度，使用简单
GRASP Low Coupling Pattern - GRASP之低耦合模式
低耦合模式（Low Coupling）是GRASP模式中为降低类之间的关联程度，适应可变性而提出的面向对象设计的原则性模式。高内聚（High Cohesion）与低耦合（Low Coupling）模式是GRASP其他模式的根本。
问题
怎么做才能降低类之间关联程度，能适应需求的变化呢？
Low Coupling模式所提倡的解决方案
为类分配职责时，应该尽量降低类之间的关联关系（耦合性）。亦即，应该以降低类之间的耦合关系作为职责分配的原则。
所谓耦合，是指多个物体（类）之间的物理或者意思上的关联程度。在面向对象方法中，类是最基本的元素，耦合主要指不同类之间相互关联的紧密程度。面向对象里的关联，主要指一个类对另一个类的调用，聚合（包含），参数传递等关系。
比如，所谓2个关联得非常紧密的类（高耦合），是指其中一个类发生变化（修改）时，另一个类也不得不跟着发生变化（修改）。
面向对象设计要求类之间满足“低耦合”原则，它是衡量一个设计是否优良的一个重要标准，因为“低耦合”有助于使得系统中某一部分的变化对其它部分的影响降到最低程度。
应用High Cohesion模式的好处
- -
高内聚（High Cohesion）与低耦合（Low Coupling）是GRASP模式的核心概念，是其它GRASP模式的根本。
优秀的面向对象设计，一般都遵从[高内聚，低耦合]原则。
独立性，有利于重用。
适应需求变化，一旦发生变化时，可以把影响缩小到最小范围。
内聚与耦合的辩证关系
1， 一方面，高内聚要求把紧密关联的功能（职责）聚集在同一个类中，防止功能的扩散和
类的无谓增加，从而减少类之间的关联，降低类之间的发生耦合的机率。 2， 另一方面，高内聚要求把不相关的功能分散到不同的类，类增加了，势必造成相互关联
类的增加，从而增大类之间发生耦合的机率。
面向对象设计，应该考虑效率，实现难度等因素，同时兼顾高内聚（High Cohesion）与低耦合（Low Coupling）性。
GRASP Controller Pattern - GRASP之控制器模式
控制器模式（Controller）是GRASP模式中解决事件处理职责问题的模式。
问题
在UI层之外，应该由哪个类来处理（控制）系统操作（事件）呢？或者说，当触发一个系统事件时，应该把对事件的处理职责分配给UI层之外的哪个层呢？
Controller模式所提倡的解决方案
把系统事件的处理职责分配给Controller（控制器）类。 担当Controller（控制器）类角色的候补类可能为： - -
系统全体，设备，子系统等的表现类（Facade Controller）
系统事件发生的用例的控制类，通常被命名为Handler，Coordinator，Session等（用例或Session的控制器）。整个系统事件都使用同一个控制器。 Controller模式相当于著名的MVC设计模式的C（Controller）部分。
类似于J2EE核心模式中的Front Controller模式（我们会在其它文章中介绍Front Controller模式）。
Controller模式提倡用一个专门的类来处理所有的系统事件。或者说Controller模式把所有系统事件的处理职责分配给一个专门的类集中处理。
应用Controller模式的好处
应用Controller模式的系统，对系统事件进行集中处理，所以： - - -
防止同类职责的分散。满足高内聚，低耦合原则。 有利于共通处理（前处理，后处理等）。
变化的高适应能力。能够把变化的修改范围控制在最小范围（控制器）之内。
Controller模式的应用例 MVC模式。
MVC模式
MVC模式Model-View-Controller头字母的缩写，中文翻译为“模型-视图-控制器” 模式（或者模型）。该模式把一个GUI应用划分为业务逻辑处理（M），画面表示（V），控制（C）三部分，并以此为基础进行设计和开发。