《对象设计和职责分配的设计模式(GRASP)》由会员分享，可在线阅读，更多相关《对象设计和职责分配的设计模式(GRASP)（12页珍藏版）》请在金锄头文库上搜索。
1、设计模式Gof设计模式GP（职责分配原则)1 Iftio ert （信息专家）信息专家模式是面向对象设计的最基本原则,是我们平时使用最多，应该跟我们的思想融为一体的原则.也就是说，我们设计对象（类）的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现.这时，这个类就是相对于这个职责的信息专家.例如：常见的网上商店里的购物车(SpCar)，需要让每种商品(SK）只在购物车内出现一次，购买相同商品,只需要更新商品的数量即可.如下图：针对这个问题需要权衡的是，比较商品是否相同的方法需要放到那里类里来实现呢？分析业务得知需要根据商品的编号(SD）来唯一区分商品,而商
2、品编号是唯一存在于商品类里的,所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。2rtor（创造者)实际应用中,符合下列任一条件的时候，都应该由类A来创建类，这时A是的创建者：. 是B的聚合. A是的容器c。 持有初始化B的信息(数据）d. 记录B的实例e 频繁使用如果一个类创建了另一个类,那么这两个类之间就有了耦合，也可以说产生了依赖关系。依赖或耦合本身是没有错误的，但是它们带来的问题就是在以后的维护中会产生连锁反应，而必要的耦合是逃不掉的，我们能做的就是正确地创建耦合关系,不要随便建立类之间的依赖关系，那么该如何去做呢?就是要遵守创建者模式规定的基本原则，凡是不符合以上条件的
3、情况，都不能随便用A创建B。例如：因为订单（rder）是商品（SKU）的容器，所以应该由订单来创建商品。如下图: 这里因为订单是商品的容器，也只有订单持有初始化商品的信息，所以这个耦合关系是正确的且没办法避免的，所以由订单来创建商品。 Lowcg(低耦合）低耦合模式的意思就是要我们尽可能地减少类之间的连接。其作用非常重要:。低耦合降低了因一个类的变化而影响其他类的范围.b。 低耦合使类更容易理解，因为类会变得简单，更内聚。下面这些情况会造成类A、B之间的耦合： A是B的属性b。 调用B的实例的方法c. 的方法中引用了B，例如B是A方法的返回值或参数。 是B的子类,或者A实现了B关于低耦合,还有
4、下面一些基本原则：a Dont alk to tngers原则:意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了啦！b。 如果A已经和B有连接,如果分配的职责给B不合适的话（违反信息专家模式),那么就把B的职责分配给A。c. 两个不同模块的内部类之间不能直接连接,否则必招报应！嘿!例如：Creator模式的例子里，实际业务中需要另一个出货人来清点订单(Oer）上的商品(S)，并计算出商品的总价,但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。如下图：这里我们在订单类里增加了一个ol
5、rice(）方法来执行计算总价的职责,没有增加不必要的耦合。4. Hihoheo （高内聚）高内聚的意思是给类尽量分配内聚的职责，也可以说成是功能性内聚的职责。即功能性紧密相关的职责应该放在一个类里,并共同完成有限的功能，那么就是高内聚合。这样更有利于类的理解和重用,也便于类的维护。高内聚也可以说是一种隔离，就想人体由很多独立的细胞组成，大厦由很多砖头、钢筋、混凝土组成，每一个部分(类）都有自己独立的职责和特性，每一个部分内部发生了问题，也不会影响其他部分,因为高内聚的对象之间是隔离开的。例如:一个订单数据存取类(OrdeD),订单即可以保存为Ece模式，也可以保存到数据库中;那么，不同的职责
6、最好由不同的类来实现，这样才是高内聚的设计，如下图： 这里我们把两种不同的数据存储功能分别放在了两个类里来实现，这样如果未来保存到xcel的功能发生错误，那么就去检查OdeAcl类就可以了,这样也使系统更模块化,方便划分任务,比如这两个类就可以分配个不同的人同时进行开发，这样也提高了团队协作和开发进度。 5. oroller(控制器)用来接收和处理系统事件的职责，一般应该分配给一个能够代表整个系统的类,这样的类通常被命名为“XX处理器”、“X协调器”或者“X会话。关于控制器类，有如下原则：a。 系统事件的接收与处理通常由一个高级类来代替。b. 一个子系统会有很多控制器类,分别处理不同的事务。关
7、于这个模式更详细的论述,请参考UML和模式应用第16章。6 Plymophism （多态)这里的多态跟OO三大基本特征之一的“多态是一个意思。例如：我们想设计一个绘图程序,要支持可以画不同类型的图形,我们定义一个抽象类hape，矩形(Retnle)、圆形(oun)分别继承这个抽象类，并重写（overre）Shap类里的Draw(）方法，这样我们就可以使用同样的接口(Shae抽象类)绘制出不同的图形，如下图：这样的设计更符合高内聚和低耦合原则,虽然后来我们又增加了一个菱形(Diaond）类，对整个系统结构也没有任何影响,只要增加一个继承Shpe的类就行了。 7。 Pure Fabrcation
8、(纯虚构）这里的纯虚构跟我们常说的纯虚构函数意思相近。高内聚低耦合，是系统设计的终极目标，但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类,但是对象之间需要协作来完成任务，这又造成了高耦合，反过来毅然.该如何解决这个矛盾呢，这个时候就需要纯虚构模式，由一个纯虚构的类来协调内聚和耦合，可以在一定程度上解决上述问题。例如：上面多态模式的例子,如果我们的绘图程序需要支持不同的系统，那么因为不同系统的AI结构不同,绘图功能也需要不同的实现方式，那么该如何设计更合适呢?如下图：这里我们可以看到，因为增加了纯虚构类Astracthape，不论是哪个系统都可以通过bstrctShpe类来绘制
9、图形,我们即没有降低原来的内聚性，也没有增加过多的耦合，可谓鱼肉和熊掌兼得,哈哈哈！ Indirtion（间接）“间接顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了,一个的变动不会影响另一个。就想我在前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合依赖关系的.9 Proectd aitios (受保护变化)预先找出不稳定的变化点，使用统一的接口封装起来,如果未来发生变化的时候，可以通过接口扩展新的功能,而不需要去修改原来
10、旧的实现。也可以把这个模式理解为OCP(开闭原则）原则，就是说一个软件实体应当对扩展开发,对修改关闭。在设计一个模块的时候，要保证这个模块可以在不需要被修改的前提下可以得到扩展。这样做的好处就是通过扩展给系统提供了新的职责,以满足新的需求,同时又没有改变系统原来的功能。关于OP原则，后面还会有单独的论述。比设计模式更重要:设计原则 1 单一职责原则(SP） “就一个类而言，应该仅有一个引起它变化的原因.”也就是说,不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责.再通俗一点地说就是，不该你管的事情你不要管,管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说
11、的多管闲事跟见义勇为是两回事,我们提倡见义勇为!） 例如:参考下图中的设计,图形计算程序只使用了正方形的ra(）方法,永远不会使用aw（）方法,而它却跟Drw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Dra(）方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。那么我们该怎么做呢?如下图，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化,这样他们也不会互相影响了. 2 开放封闭原则（CP) “软件实体（类、模块、函数等)应该是可以扩展的，但是不可修改。”嘿!多么朴实的话语，第一次看这个原则的时候我都看傻了,我当时在想“这不是#做白日梦吗!不修改怎么扩展
12、啊？但是随着学习的深入，理解了这个“不修改”是什么意思，意思是“你可以随便增加新的类，但是不要修改原来的类”.从这个角度去理解就好多了,其实这里还是一个隔离变化的问题. 例如:如下图,有一个客户端程序通过数据访问接口操作数据，对于这套系统来说，一开始计划使用的是SLSrver或Orale数据库，但是后来考虑到成本，改用免费的MyQL；那么对于客户端程序来说，后来数据的扩展对它没有任何影响，它在不知不觉间就用上了免费好用的yL数据库，这全要感谢OCP原则。3。 依赖倒置原则（DP)“抽象不应该依赖于细节。细节应该依赖于抽象。”关于这个原则，还有种说法是.“高层不应该依赖于底层,两者都应该依赖于抽
13、象。”其实怎么说都是对的，关键就是要理解一点,只有抽象的东西才是最稳定的,也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！哈哈！例如：参考下图的设计,一个开关跟灯直接连接在一起了,也就是说开关依赖于灯的打开和关闭方法,那么如果我想用这个开关也可以打开其他东西呢，比如电视、音响.显然这个设计是无法满足这个要了,因为我们依赖了细节而不是抽象，这个开关已经等价于“灯的开关。 那么我们该如何来设计一个通用的开关呢？参考下图的设计，OK！现在我们不仅可以打开灯，还可以打开电视和音响,甚至未来任何实现了“开关接口”的任何东西. 4。 接口隔离原则（I
14、S) “不应该强迫客户依赖于它们不用的方法.接口属于客户，不属于它所在的类层次结构。这个说得很明白了,再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。例如:参考下图的设计，在这个设计里，取款、存款、转帐都使用一个通用界面接口，也就是说,每一个类都被强迫依赖了另两个类的接口方法,那么每个类有可能因为另外两个类的方法（跟自己无关）而被影响。拿取款来说，它根本不关心“存款操作”和“转帐操作”，可是它却要受到这两个方法的变化的影响，真是土鳖！!那么我们该如何解决这个问题呢?参考下图的设计,为每个类都单独设计专门的操作接口,使得它们只依赖于它们关系的方法,这样就不会互相影响,也就不会在发生土鳖的事情了！5 替换原则（LSP） “子类型必须能够替换掉它们的基类型。”也就是说继承中的“IS A”关系是必须保证的，否则还算什么继承啊!如果违反了LP原则，常会导致在运行时（RTT）
