(构造笔记)GRASP学习心得

(构造笔记)GRASP学习心得

GRASP学习

通过网上资料了解到，GRASP是通用职责分配软件模式(General Responsibility Assignment Software Patterns)的缩写，能够帮助我们理解基本对象的设计，提高面向对象设计(OOD)的觉悟。
GRASP总共有9中模式分别是：

1、高内聚、低耦合（High Cohesion、Low Coupling）

在面向对象的程序设计时，小到一个类，大到一个功能模块，如果他们之间的相依性很高就会对整个软件的开发造成诸般障碍。例如：当你修改一个类或者某一个模 块的时候，相应的你要改动其他的与之相依赖的类和模块，使得程序很难维护；代码会变得很难理解，一个很单一的操作，就会涉及到很多程序之间相互调用；程序 更是难以复用，当你想复用一个类的时候，对应的与之想依赖的类或方法也会被陆陆续续的添加进来。
这就是我们为什么要遵循这一原则的原因，而高内聚和低耦合往往是伴随在一起出现的。低耦合其实就是两个类或模块之间联系的紧密程度，高内聚就是类中方法和 方法之间的职责相关性。要想避免低内聚、高耦合，解决办法就是既要降低因为一个类的变化而对另一个类产生的影响，又要保持类或模块是有重点的、可理解的、 可管理的并且支持低耦合的，也就是更加精确的给一个类或者模块分配职责。
高内聚和低耦合是软件开发中最重要的原则，grasp的其他模式也是以高内聚、低耦合原则为中心的。

2、信息专家(Information Expert)
如何实现高内聚，也就是如何给类分配职责？我们要遵循的原则就是把职责分配给具有完成该职责信息的那个类。

3、创建者（Creator）
如何分配创建对象的职责呢？原则就是当下列条件满足时（越多越好），由B创建A：
1.B频繁的使用A
2.B包含或聚合了A
举个简单的例子，如果类A实现了B接口，类C、D是类A的一个属性，那么C、D应该由A来创建，A应该由B来创建。如果C、D由B来创建，那么当C或者D改变的时候，B 和A也要跟着改变，大大增强了B和C、D的之间的耦合度，违背了低内聚的原则。通俗点说就是如果B使用的了A，那么就应该由B来创建A，而不是由其他的类来创建。

4、控制器（Controller）
在UI层外，应该由哪个类来处理系统操作呢？原则就是把系统事件的处理职责分配给控制器类，这个控制器类就相当于MVC中的C。这个控制器类通常是系统事件放生 的用例的控制类。

5、多态（Polymorphism）
根据类型的不同而发生变化的行为的定义职责，应该分配给谁？
举个简单的例子，坐车去广州，坐车算是一个行为，但是这个行为是可以变化的，比如坐飞机、坐汽车或者坐火车，那么坐车这个行为的定义应该分配给谁呢？
原则是通过多态操作把基于类型的可变行为的定义职责分配给发生该行为的类。放到JAVA当中来实现就是定义一个坐车的接口，然后具体的坐飞机、坐汽车或者坐火 车的行为分别定义一个类来实现该功能，然后让这三个具体的类去实现坐车接口。

6、纯虚构模式（Pure Fabrication）
非问题领域的职责应该分配给谁？
我们在设计类的时候，通常都尽量的保持和现实世界当中的对象一致，那么我们从现实世界的对象抽象出来的类就叫做问题领域里的类，那么当我们保存这个对象的 时候要操作数据库，操作数据库就是一个非现实世界存在的业务对象，他就是非问题领域的职责。
这种职责分配的原则就是将非问题领域的职责分配给人工生成的类。比如问题领域的类通常是放到PO里面的，他不应该包括CRUD等操作。那么CRUD这些操作应该放 到一个人工生成的也就是我们在业务逻辑以外加的一个类。

7、间接性（Indirection）
为了避免两个或多个事物之间直接耦合，应该如何分配职责？
设计原则是将职责分配给中介对象。例如类A和类B是多对多的关联关系，当A改变的时候，B需要做相应的改变，当B改变的时候，A需要做相应的改变，这是违反低耦 合原则的，解决方法就是在A和B之间加入一个C类，类C的属性只有A和B，用C来记录A和B之间的关系，当A想使用B或者B使用A的时候，他们都通过C来调用对方。

8、防止变异（Protected Variation）
如何设计对象、系统和子系统，使其内部的变化或者不稳定因素不会对其他元素产生不良影响？
预计识别不稳定的因素，在其外部创建稳定的接口。例如：坐汽车去广州当中的坐汽车就是一个不稳定的因素，以后也许会坐飞机或者火车，那么我们就要把坐汽车 抽象出一个坐车的接口，当有一天想坐火车的时候直接加一个实现的类就可以了。
设计模式是咋样解决设计问题的呢：
首先：描述对象的实现（依赖关系）
1、对象通过 实例化类来创建，此对象被称为该类的实例。2、当实例化类时，要给对象的内部数据（由实例变量组成）分配存储空间，并将操作与这些数据联系起来。3、新的类可以由已存在的类通过 类继承（class inheritance）来定义。
当子类（subclass）继承父类（parent class）时，子类包含了父类定义的所有数据和操作。子类的实例对象包含所有子类和父类定义的数据，且它们能完成子类和父类定义的所有操作。子类能 重定义（override）父类定义的操作。重定义使得子类能接管父类对请求的处理操作。
抽象类（abstract class）的主要目的是为它的子类定义公共接口，一个抽象类要把它的部分或全部操作的实现 延迟到子类中[Factory Method]，一个抽象类不能被实例化
在抽象类中定义却没有实现的操作被称为 抽象操作（abstract operation）
非抽象类称为 具体类（concrete class），混入类（mixin class）是给其他类提供可选择的接口或功能的类， 它与抽象类一样不能实例化
混入类要求多继承，一个对象的 类（class）定义了对象是怎样实现的，同时也定义了对象的内部状态和操作的实现，一个对象的 类型（type）只与它的接口有关，接口即对象能相应的请求的集合，一个对象可以有多个类型，不同类的对象可以有相同的类型，类继承，根据一个对象的实现定义了另一个对象的实现，它是代码和表示的 共享机制，接口继承（或子类型化）描述了一个对象什么时候能被用来 替代另一个对象。
对接口编程，而不是对实现编程，继承所拥有的定义 具有相同接口的对象族的能力是很重要的（通常可以从抽象类来继承）。因为 多态依赖于这种能力，当继承被恰当使用时，所有从抽象类导出的类将共享该抽象类的接口。 这意味着子类仅仅添加或重定义操作，而没有隐藏父类的操作，这时，所有的子类都能响应抽象类接口中的请求，从而 子类的类型都是抽象类的子类型，只根据抽象类中定义的接口来操纵对象有以下两个好处：
1）客户无须知道他们使用对象的特定类型，只须对象有客户所期望的接口
2）客户无须知道他们使用的对象是用什么类来实现的，他们只需知道定义接口的抽象类
这将极大地减少子系统实现之间的相互依赖关系
通过抽象对象的创建过程， 创建型模式提供不同方式以在实例化时建立接口和实现的透明连接
创建型模式确保你的系统是采用针对接口的方式书写的，而不是针对实现而书写的。
————————————————
版权声明：本文为CSDN博主「qq_43833476」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_43833476/article/details/117040114