设计模式的基础： GRASP (中)

4、Creator (创造者)

       前一篇帖子中的高内聚、低耦合和信息专家者对我们阐明了对象、模块在被合理地创建后，应该长什么样子，它们之间应该有怎么样的关系。然而如何创建呢？GRASP的Creator给了我们一个大的原则。

       在实际的开发过程中，当满足以下任意一个条件的时候，B类都应该由A类来创建，这时候A类是B类的创造者：  

       1.       Ａ包含或聚合了Ｂ

       2.       Ａ是Ｂ的容器

       3.       Ａ持有初始化Ｂ的信息(数据)

       4.       Ａ记录Ｂ的实例

       5.       Ａ频繁使用Ｂ

       例子：1、如果类A实现了B的接口，类C、D是类A的属性，那么C、D应该由A来创建，A应该由B来创建。如果C、D由B来创建，那么当改

                变C或者D的时候，A和B都要跟着修改，这样就大大增加了B和C、D之间的耦合度

             2、因为订单(Order)是商品(SKU)的容器，所以应该由订单来创建商品。如下图：

                这里因为订单是商品的容器，也只有订单持有初始化商品的信息，所以这个耦合关系是正确的且没办法避免的，所以由订

                单来创建商品。

5、Controller (控制器)

    在UI层外，应该由哪些类来处理程序系统的操作呢？Controller模式告诉我们要把程序系统事件的处理职责分配给控制器类，也就是MVC中的C，iOS SDK 将 MVC 贯彻得很彻底，而Android在这方面就比较不那么明显，至少在我看来是这样子的(果然还是水平不够的原因...)。    

        关于控制器类，有如下原则：

        a.       系统事件的接收与处理通常由一个高级类来代替。

        b.       一个子系统会有很多控制器类，分别处理不同的事务。

    关于这个模式更详细的论述，请参考《UML和模式应用》第16章。

6、Polymorphism (多态)

        这里的“多态”和OO里面的“多态”是一个意思。试想一下这样一个问题：因为类型不同而发生变化的这些行为所定义的职责应该分配给谁？比如说我要去上海，坐车去是一个行为，但是这个行为是可以变化的，比如坐飞机或者坐火车去，那么去上海这个职责要分配给谁呢？

    原则上来说是通过多态操作把基于类型的可变行为的定义职责分配给发生该行为的类。放到Java中来实现，就是定义一个去上海的接口，然后具体是做飞机、火车等的行为分别定义多个类来实现这些功能，然后这些类去实现去上海的接口。

    例子：我们想设计一个绘图程序，要支持可以画不同类型的图形，我们定义一个抽象类Shape,矩形(Rectangle)、圆形(Round)分别继承

          这个抽象类，并重写(override)Shape类里的Draw()方法，这样我们就可以使用同样的接口(Shape抽象类)绘制出不同的图形，如 

          下图：

          这样的设计更符合高内聚和低耦合原则，虽然后来我们又增加了一个菱形(Diamond)类，对整个系统结构也没有任何影响，只要增

          加一个继承Shape的类就行了。