简述GRASP设计原则
通用角色分配模型(grasp )是一种通用的角色软件分配模型。 GRASP的核心是自己做自己能做的事，自己只做自己的事。 这意味着实现角色分配和高度凝聚。 用于解决面向对象设计中的几个问题。 GRASP提出了九个原则。 以下，笔者就这9个设计原则进行阐述。
高聚集、低偶联(High Cohesion，Low Coupling ) )。
对于面向对象的编程，小到一个类，大到一个功能模块，他们之间的依赖性高会给整个软件开发带来各种障碍。 例如，当修改包含明亮画板的类或模块时，会相应地修改其他依赖的类和模块，从而使程序难以维护； 代码变得难以理解。 单一操作会涉及许多程序之间的相互调用，而且程序很难重用，如果明亮的画板想重用一个类，相应的想依赖的类和方法也会不断添加。
所以我们遵循这个原则，高凝聚和低耦合往往一起出现。 低耦合实际上是两个类或模块之间联系的紧密程度，高凝聚是类中方法和方法之间责任的关联性。 为了避免低凝聚、高结合，类别或模块是重要的、可理解的、可管理的，并支持低结合，即更准确地将责任分配给一个类别或模块，同时降低一个类别的变化对其他类别的影响
高聚集和低耦合是软件开发中最重要的原则，grasp的其他模型也以高聚集、低耦合原则为主。
信息专家(Information Expert )
如何实现高聚集？ 也就是说，你怎么给班级分配责任？ 我们应该遵循的原则是，将责任分配给拥有完成该职责的信息的类。
创建者(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。
控制器)。
在UI层之外，哪些类应该处理系统操作呢？ 原则上，将处理系统事件的责任分配给控制器类。 这个控制器类相当于MVC的c。 该控制器类通常是发生系统事件的用例的控制类。
多态性)。
根据类型而变化的行为的定义角色应该分配给谁？
举个简单的例子，坐车去广州。 坐车是一种行为，但这种行为可以改变。 例如，坐飞机、汽车或坐电车。 那么，坐车这个行为的定义应该分配给谁呢？
策略是通过多态性操作将定义基于类型的可变行为的责任分配给发生该行为的类。 放入JAVA中实现是定义一个车接口，并对具体的飞机、汽车或电车行为分别定义一个类实现其功能，然后在这三个具体类中实现车接口
纯粹虚构模式(Pure Fabrication ) )。
非问题领域的责任应该分配给谁？
我们设计类时，通常会尽量与现实世界中的对象保持一致。 这样我们就把从现实世界对象中抽象出来的类称为问题区域的类。 那么，我们保存这个对象的时候就操作数据库。 操作数据库是存在于非现实世界中的业务对象，他是非问题领域的角色。
这个任务分配的原则是将非问题领域的任务分配给人工生成的类。 例如，问题领域的类通常被放入PO中，其他不应该包含CRUD等操作。 CRUD中的这些操作必须放在手动生成的类中，也就是在业务逻辑之外添加的类中。
间接性。
应该如何分配责任，以免两个以上的东西直接结合？
设计原则是将责任分配给中介对象。 例如，a类和b类是多对多的关联关系，当a发生变化时，b需要相应改变，当b发生变化时，a需要相应改变。 这违反了低耦合原则。 解决方法是在a和b之间加入c类，c类的属性只有a和b，用c记录a和b的关系，当a想用b，或者b想用a时，他们用c呼叫对方。
抗变异(Protected Variation )
如何设计对象、系统和子系统，以避免其内部的变化或不稳定因素对其他因素产生负面影响？
预计将识别不稳定的因素，并在其外部创建稳定的接口。 例如，在开车去广州的过程中坐车是一个不稳定的因素，以后可能会坐飞机或者火车。 那么，抽象出乘坐汽车的接口，添加某一天想坐火车时直接实现的类就可以了。