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:面向对象的基本原则的几种缩写