GRASP(General responsibility assignment software Principle)设计原则是设计模式的基础,在GOF的23中设计模式中处处可以体现其中的一个或多个设计原则,所以在掌握设计模式之前需要对GRASP原则有一定的了解,本节我在这里总结一下grasp原则。
本文共分为以下几个内容:
信息专家模式的本质指的是我们应该将职责委托给哪一个对象,这个职责可以是一个方法,也可以是一个算法或者其他内容。它是面向过程设计过程中最基本的原则。
委托原则:我们在设计对象的时候,如果某个对象拥有完成某个职责所需要的所有信息,那么这个职责就分配给这个对象实现。这个时候,这个类就是相对于这个职责的信息专家。
示例:我们在设计购物网站的时候,为避免重复,一种商品只能在购物车中出现一次,如果多次出现,则需要将其数量增加。这个时候我们在将物品放入购物车的时候,要首先判断当前物品是否在购物车中,判断两个物品是否为同一个物品的方法这个职责应该委托给谁呢?显而易见,商品类中有唯一标识,所以这个职责由商品类实现,而不是购物车。
creator原则的本质是创建类对象职责应该委托给那个对象,也就是谁应该负责产生某个类的实例。
解决方案: 如果符合下面的一个或者多个条件,则可以将创建A的实例的职责分配给B;
满足上述一种或者多种情况的时候,我们应该奖创建A的实例的职责分配给B。
合理的creator原则带来的优点:如果职责分配合理,设计就能降低耦合,提高设计的清晰度,封装性和重用性。
示例:例如订单和商品的关系是聚合关系,这个时候我们将在订单中创建商品。
耦合是评价一个系统中各个元素之间连接或者依赖关系强弱的尺度。低耦合的原则是我们在设计系统的时候尽量降低系统中各个元素之间的耦合度,这样对于系统的理解和维护都有很大的益处。
耦合性高的系统会带来的坏处:
两个类具有以下特性中的其中一个,我们就说这两个类是耦合的:
低耦合系统的设计方法:
内聚是评价一个对象的职责被关联的尺度或者强弱,也可以说是功能性内聚的职责。也就是功能性紧密的相关职责应该放在同一个类中,并共同完成有限的功能。这样做更加有利于对类的理解和重用,也可以降低类的维护成本。
往往低内聚的系统设计会导致类的混乱,当对功能进行扩展或者改进的时候带来不必要的麻烦,低内聚的类也不利于重用,因为他们的职责如此之混乱。
为了达到高内聚,我们需要对类的职责进行分解,使分解出来的类具有独立的职责,满足单一职责原则。将一些需要在多个类中使用到的方法封装到一个类中,其他的类只负责他们需要负责的相关功能,这样我们可以提高类的内聚程度。
控制器模式的实质是将一些系统事件的接受和处理委托给一个的对象controller,这个对象可以是一个类,系统或者子系统,它不与UI进行交互,它只负责系统信息的接收和处理。
一般情况下,控制器是一个系统,这个系统中包括多个处理器,分别对应处理不同的事务。通常情况下,一个控制器应当把要完成的功能委托给其他对象,而它只负责任务的协调控制和分配。
控制器原则与MVC模式相对应,MVC模式是一种比设计模式更高的架构模式。
多态原则与面向对象设计原则中的多态概念类似,这里不再详细赘述。
纯虚构原则与我们所说的纯虚函数类似。
纯虚构的作用是用来解决高内聚和低耦合之间的矛盾的。高内聚低耦合是我们系统设计的终极目标,高内聚意味着我们要将类拆分成多个功能集中的类,但是拆分的多个类之间需要进行协作才能正常工作,这样又增加了类之间的耦合性。
纯虚构原则是用来解决上述问题的方案。它要求将一部分类的职责转移到纯虚构类中,在理想的情况下,分配给这种虚构类的职责是为了达到高内聚低耦合的效果。在实际的操作过程中,纯虚构类的实现又很多种方式,例如将数据库中操作的方法从数据库实体中分离出来,形成专门的数据访问类;通过对类的分解来实现类的重用,新增加的数据访问类对应于数据的持久化存储,这是软件开发过程中为了方便虚构出来的一个概念。一般情况下,纯虚构模式通常基于功能进行划分的。
中介模式的目的是为了避免两个对象之间产生直接耦合,降低对象之间的耦合度。
解决方案是建立中间对象来协调两个对象之间的交互,避免耦合性过高。
受保护模式的实质与OCP(开放闭合原则)类似,我们首先找到系统中不稳定的变化点,使用统一的接口封装起来,如果未来发生变化的时候,可以通过扩展接口来扩展新的功能,而不需要改变旧的代码。这样达到易于扩展的目的。
文章转载自:https://langzi989.github.io/2017/01/08/GRASP%E8%AE%BE%E8%AE%A1%E5%8E%9F%E5%88%99%EF%BC%88%E8%81%8C%E8%B4%A3%E5%88%86%E9%85%8D%E5%8E%9F%E5%88%99%EF%BC%89/