依赖原则

前端之家收集整理的这篇文章主要介绍了依赖原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

猜你在找的设计模式相关文章