GRASP模式
作者：互联网
GRASP，全称为Geneal Repsibily Asgren Sotware Pattern即通用职责分配软件模式，它由Applying UML and Patterns (UML和模式应用)一书作者CraigLarman提出。与其将它称为设计模式，不如称为设计原则，因为它是站在面向对象设计的角度,告诉我们怎样设计问题空间中的类与分配它们的行为职责，以及明确类之间的相互关系等，而不像GoF模式一样是针对特定问题而提出的解决方案。因此GRASP站在一个更高的角度来看待面向对象软件的设计,它是GoF设计模式的基础。
GRASP是对象职责分配的基本原则，其核心思想是职责分配(Responsibility Assignment),用职责设计对象(Designing Objets with Responsibilities),它包含如下9个基本模式。
1.信息专家模式(Information Eperxt Pattern)
信息专家模式是面向对象设计的最基本原则。通俗地讲，就是一个类只干该干的事情，不该干的事情不干。在系统设计时,需要将职责分配给具有实现这个职责所需要信息的类。信息专家模式对应于面向对象设计原则中的单一职责原则。
2.创造者模式(Creator Pattern)
创建对象是面向对象系统中最普遍的活动之一，因此，确定一个分配创建对象的通用职责非常重要。如果职责分配合理，设计就能降低耦合，提高设计的清晰度、封生性和重用性。通常情况下，如果对象的创建过程不是很复杂，则根据上述原则，由使用对象的类来创建对象。但是如果创建过程非常复杂，而且可能需要重复使用对象实例或者需要从外部注人一个对象实例，此时，可以委托一个专门的工厂 类来辅助创建对象。创建者模式与各种工厂模式(简单工厂模式、工厂方法模式和抽象工厂模式)相对应。
3.低耦合模式（Low Coupling Pattern）
耦合是评价一个系统中各个元素之间连接或依赖强弱关系的尺度，具有低耦合的元素不过多依赖其他元素。此处的元素可以是类，也可以是模块、子系统或者系统。具有高耦合的类过多地依赖其他类，这种设计将会导致:一个类的修改导教其他类产生较大影响:系统难以维护和理解:系统重用性差，在重用一个高耦合的类时不得不重用它所依赖的其他类。因此需要对高耦合的系统进行重构。
类A和类B之间的耦合关系体现如下: A具有一个B类型的属性: A调用B的方性，A的方法包含对B的引用，如方法参数类型为B或返回类型为B: A是B的直接或者间接子类; B是一个接口，A实现了该接口。低耦合模式鼓励在进行职责分配时不增加耦合性，从而避免高耦合可能产生的不良后果。在进行类设计时,需要保持类的独立性，减少类变更所带来的影响，它通常与信息专家模式和高内聚模式已一起出现。 为了达到低耦合，我们可以通过如下方式对设计进行改进
●在类的划分上，应当尽量创建松耦合的类,类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及。
●在类的设计上,每一个类都应当尽量降低其成员变量和成员函数的访向权限。
●在类的设计上，只要有可能，一个类型应当设计成不变类。
●在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
4.高内聚模式（High Cohesion Pattern）
(3)内聚是评价一个元素的职责被关联和关注强弱的尺度。如果一个元素具有很多紧密相关的职责，而且只完成有限的功能。则这个元素就具有高内聚性。此处的元素可以是类，也可以是模块、子系统或者系统。
在个低内聚的类中 会执行很多互不相关的操作 .这将导致系统难于理解、难于重用、难于维护、过于脆弱,容易受到变化带来的影响。因此我们需要控制类的粒度在，分配类的职责时使其内聚保持为最高,提高类的重用性,控制类设计的复杂程度。为了达到低内案，我们需要对类进行分解,使得分解出来的类具有独立的职责,满足单一职责原则。在一个类中只保留一组相关的属性和方法,将些需要在多 个类中重用的属性和方法或完成其他功能所需的属性和方法封装在其他类中。类只处理与之相关的功能，它将与其他类协作完成复杂的任务。
5.控制器模式（Controller Pattern）
一个控制器是负责接收或者处理系统事件的非图形用户界面对象。一个控
制器定义一组系统操作方法。在控制器模式中，要求系统事件的接收与处理通常由一个高级类来代替;一个子系统需要定义多个控制器,分别对应不同的事务处理。通常，一个控制器应当把要完成的功能委托给其他对象，它只负责协调和控制,本身不完成太多的功能。它可以将用户界面所提交的请求转发给其他类来处理,控制器可以重用，且不能包含太多业务逻辑，一个系统通常也不能设计一个统一的控制器。
6.多态模式（Polymorphism Pattern）
由条件化引发同类型的不同行为是程序的一个基本主题. 如果用if-else或switch-case等条件语句来设计程序，当系统发生变化时必须修改程序的业务逻辑，这将导致很难方便地扩展有新变化的程序。另外对于服务器/客户端结构中的可视化组件，有时候需要在不影响客户端的前提下,将服务器的一个组件替换成另一个组件。此时可以使用多态来实现,将不同的行为指定给不同的子类，多态是设计系统如何处理相似变化的基本方法,基于多态分配职责的设计可以方便地处理新的变化。在使用多态模式进行设计时，如果需要对父类的行为进行修改，可以通过其子类来实现,不同子类可以提供不同的实现方式，将具体的职责分配给指定的子类。新的子类增加到系统中也不会对其他类有任何影响，多态是面向对象的三大基本特性之一(另外两个分别是封装和继承) ,通过引入多态，子类对象可以覆盖父类对象的行为,更好地适应变化，使变化点能够“经得起未来验证”。多态模式在多个GoF设计模式中都有所体现，如适配器模式、命令模式、组合模式、观察者模式策略模式等。
7.纯虚构模式（Pure Fabrication Pattern）
纯虚构模式用于解决高内聚和低耦合之间的矛盾，它要求将一 部分类的职责转移到纯虚构类中，在理想情况下，分配给这种虚构类的职责是为了达到高内聚和低耦合的目的。在实际操作过程中，纯虚构有很多种实现方式，例如将数据库操作的方法从数据库实体类中剥离出来,形成专门的数据访问类，通过对类的分解来实现类的重用，新增加的数据访问类对应于数据持久化存储，它不是问题域中的概念,而是软件开发者为了处理方便而产生的虚构概念。纯虚构可以消除由于信息专家模式带来的低内聚和高耦合的坏设计，得到一个具有更好重用性的设计。在系统中引人抽象类或接口来提高系统的扩展性也可以认为是纯虚构模式的一种应用。在很多设计模式中都体现了纯虚构模式，例如适配器模式、策略模式等。
8.中介模式（Indirection Pattern）
要避免对象之间的直接耦合，最常用的做法是在对象之间引人一个中间对象或中介对象，通过中介对象来间接相连。中介模式对应于面向对象设计原则中的迪米特法则，在外观模式、代理模式、中介者模式等设计模式中都体现了中介模式。
9.受保护变化模式(Protected Variations Pattern)
受保护变化模式简称PV,它是大多数编程和设计的基础，是模式的基本动机之一，它使系统能够适应和隔离变化。它与面向对象设计原则中的开闭原则相对应，即在不修改原有元素(类、模块、子系统或系统)的前提下扩展元素的功能。开闭原则又可称为“可变性封装原则( Principle of Encapsulation of Variation, EVP)”,要求找到系统的可变因素并将其封装起来。如将抽象层的不同实现封装到不同的具体类中,而且EVP要求尽量不要将一种可变性和另一种可变性混合在一起,这将导致系统中类的个数急剧增长，增加系统的复杂度。在具体实现时，为了符合受保护变化模式，我们通常需要对系统进行抽象化设计,定义系统的抽象层,再通过具体类来进行扩展。如果需要扩展系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，在不修改已有代码的基础上扩展系统的功能。大多数设计原则和GoF模式都是受保护变化模式的体现。
设计模式的使用
设计模式在软件开发中的两个主要用途。
开发人员的共同平台
设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。
最佳的实践
设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。
下面给说一下策略模式的解决设计问题的方法
介绍
意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。
何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。
如何解决：将这些算法封装成一个一个的类，任意地替换。
关键代码：实现同一个接口。
应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。
优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。
使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。
实现
我们将创建一个定义活动的 Strategy 接口和实现了 Strategy 接口的实体策略类。Context 是一个使用了某种策略的类。
StrategyPatternDemo，我们的演示类使用 Context 和策略对象来演示 Context 在它所配置或使用的策略改变时的行为变化。
标签：职责,系统,模式,耦合,GRASP,设计,设计模式 来源： https://blog.csdn.net/weixin_45234773/article/details/116944849