依赖原则

2.2依赖原则

1.接口一方面作为抽象类型，描述了一类对象所遵循的行为规范，另一方面作为间接层，把两个耦合的具体类进行分离。

2.高层模块不应该依赖底层模块，它们都应该依赖抽象，抽象不应该依赖细节，细节应该依赖抽象

3.依赖不会消失只会转移，责任和权利也一样

4.抽象与规范时根本，间接和分离是手段。依赖和控制是关键，接口和服务时核心

5.接口一种抽象，因为它隐藏实现细节

  接口一种规范，因为它定义服务契约

  接口是一种间接，同时还是实现间接层的关键手段，接口可以产生分离，规范与实现分离，职责分离，关注度分离

接口作为解耦点，可以消除非本质依赖。接口作为反向控制点，可以抽象地调用

局部依赖而无需顾忌它们的具体实现

2.2内聚原则

1.众所周知，模块化的目的是把一个复杂的系统分解为若对简单点，具有特定功能的软件单元。以便分而治之，为此，

每个模块的职责应当单一而明确，模块之间的关键应当局部而清晰，即遵循低耦合高内聚的原则，以保障软件的

可理解性，可维护性，可重用性。

2.耦合当然不可完全消除，因为模块之间是同耦合来相互协作的

3.如果发现两个模块的依赖关系过于紧密，以致降低他们的耦合做法是徒劳无益的，那么狠可能二者有本质的关联。

不妨将它们合为一体。原则高耦合的缺点立马变成高内聚的优点

4.又是违背SRP是情有可原，毕竟类的职责难以被清晰地界定，关键还是看他们对变化的反应

5SRP给我们提供一个启示：每个类都是单一职责的抽象，也是单一变化的封装，这表明：一耳光理想的类在其所在的抽象层次上，即

是一个最小的可重用的单元，也是一个最小的可维护的单元。

2.4保变原则

1.该原则的内容是：找出预计的变化点或不稳定点，分配其职责便用稳定的接口在包装。

2.软件越复杂，寿命约长，可维护性越重要。因为软件维护是软件生命周期中耗时最长，最多的一个阶段。

3.事实上，越是接近客户需求前沿的类，越容易发生变化，稳定度就越低，有些修改时非常正确的，因此，一味地苛求高层代码具有高

重用性，不仅是不必要的，更是不现实的。

4 GRASP 掌握  SOLID 牢固

GRASP:通用的职责分配   SOLID:面向对象的基本原则的几种缩写