S: 单一职责原则 即一个类只应承担一种责任，即让一个类只做一件事。如果需要承担更多的工作 需要分解这个类。
O: 开放封闭原则 实体应该对拓展是开放的 对修改是封闭的
L:里式替换原则：一个对象出现在其他任何地方 都可以用子类实例作为替换 并且不会导致程序错误。也就是说 当子类可以在任何地方替换父类而不受影响时 这种继承关系的建模才是合理的。
I:接口分离原则：客户不应该被强迫依赖他不使用的方法。即，一个类实现的接口中，如果包含了它不需要的方法 那么我们就要将接口拆分成更小和更具体的接口， 有助于解耦，从而使代码更容易重构更改。
D：依赖倒置原则：高层次的模块不应该依赖于低层次的模块 他们应该更加依赖于抽象，实际上 依赖倒置使实现开闭原则的方法。
GRASP:（通用职责分配软件原则）：
https://nicky-zs.github.io/2014/02/09/GRASP/
其实这九种原则就是设计模式
Information expert: 关注的问题：给对象分配职责的基本原则是什么？
Creator:创建者模式关注这样一个问题，假设系统中存在一个类A。那么在这个系统中 谁应该负责创建A的实例呢？
Controller: 关注的问题：在UI蹭上首先接收和协调系统操作的第一个对象是什么？
Low Coupling:关注的问题：如何降低代码之间的依赖性 减少某部分变化所带来的整体的影响，提高代码的重用性？
High cohesion:问题：如何保持对象是有重点地 可理解的 可管理的 并且能够支持低耦合？
Polymorphism:问题:如何处理基于类型的选择 如何创建可插拔的软件构件？
Pure Fabrication:问题：当并不像违背高内聚和低耦合，但是基于专家模式所提供的方案又不适合 哪些对象应该承担这一职责？
indirection: 问题：为了避免两个或者多个事务之间的直接耦合 应该如何分配职责？如何使对象解耦合以支持低耦合从而提高复用性潜力？
Protected Variations:问题：如何设计对象，子系统或者系统，使得其内部的变化或不稳定性不会对其他元素产生不良影响？
