进阶之光 第六章...
本文 只做笔记 记录,不具其他价值,如有侵权,请联系作者删除...
设计模式 六大原则:
1. 单一职责
就一个类 而言,应该仅有一个 引起她 变化的原因
我们不应该让一个类 承担过多 的 职责...
等于把这些职责 耦合到一起, 这种耦合会导致脆弱的设计...当发生变化时,设计遭到破坏...
单一 职责的 划分界限不是很清晰,有时候 依靠个人经验来界定, 她是一个饱受争议却有极为重要的原则...
2. 开放封闭 原则
类, 模块, 函数 等 应该 是可以拓展的,但是不可修改...
需求可以有新的变化,
尽可能保证相对稳定..
3. 里氏替换原则
所有引用 基类 的地方 必须哪呢个透明使用其子类的对象..
她 告诉我们,在软件中,将一个基类对象替换成其子类对象,程序将不会发生错误...反过来则不成立
子类所有方法 必须在父类申明,或是子类必须实现父类申明的所有方法
为了保证系统的拓展性,在程序中通常使用 父类进行定义
如果 一个方法 只存在于 子类,在父类中,不提供相应的申明,则无法在以父类定义的对象中 使用该方法..
在 运用里氏替换原则时, 尽量 设计父类为 抽象类或是接口,让子类继承,或是实现父类接口 并且实现父类申明方法
4. 依赖 倒置 原则
高层模块 不应该依赖 低层模块,两者都 应该依赖抽象
抽象 不应该依赖于 细节, 细节 应该依赖于 抽象...
在 java ...
抽象指 接口或是抽象类
两者 都是不能直接 实例化的
细节 就是实现类,实现接口或者是继承抽象类而产生的 就是细节 (也就是 可以加上一个new 产生的对象)
高层模块 是 调用端,低层模块 就 是 具体实现类
依赖倒置 原则 在java 中的体现是 模块之间的依赖 通过抽象发生( ??? ) 实现类 之间不发生直接依赖关系
其依赖关系 是通过接口 或是抽象类产生的...
如果 类与类之间 直接依赖细节,那么就会直接耦合.... 如此以来,当修改时,就会同时修改依赖者 代码 ,这样限制了拓展 性...
5. 迪米特 原则
一个软件实体 尽 可能少的与其他实体 发生相互作用...
也被称为 最小知识 原则
如果 一个系统符合 迪米特原则, 那么当 某一个模块发生 修改时, 就会尽量减少影响其他 模块...
应该尽量减少对象 直接的交互
如果两个对象之间 不必彼此通信,那么这两个对象 就不应该 发生 任何直接的 相互作用
(如果其中一个对象要调用另一个对象方法时,可以通过第三者转发这个调用)
6. 接口隔离 原则
一个类对另一类的依赖 应该建立在最小 接口上
建立单一的接口,不要建立 庞大臃肿的
尽量细化
接口中方法尽量少
要为各个类 建立专用的接口 不要试图建立一个很庞大的接口供所有依赖她的类 调用...
约束:
接口尽量少,但是要有限度, 适度(否则会造成接口数量过多)
为依赖接口的类 定制服务, 只暴露给调用 的类 需 要 的方法
提高内聚,减少对外交互 接口方法尽量少用 public 修饰, 接口是对外的承诺,承诺越少,对系统开发 越有利 变更的风险也就越少