设计模式六大准则

1. 单一职责原则
   一个类应该只有一个引起它变化的原因
2. 里氏替换原则(继承)
   引用父类的地方必须能透明得使用其子类
3. 依赖倒转原则
   面向接口编程而不是面向实现
4. 接口隔离原则
   单一的总接口×，多个专门的接口√
5. 迪米特法则
   使实体尽可能得与其他实体相互作用
6. 开闭原则
   整个项目尽量在不修改原有代码的情况下进行扩展

单一职责准则

关于功能划分的准则

高内聚,低耦合,从变更的角度来看,一个类完成的职责越简单,在变更它的时候就越方便,具体就体现在修改代码的难度/代码变更可能导致BUG的多少/可读性等...

但是这一准则的实现更多得是看程序员得经验和思路,对于未来变化得发生进行一个合理的预判
这里罗列一下单一准则的好处

1. 降低类的复杂度
2. 提高可读性,从而提高系统的可维护性
3. 可以使得变更代码引起的风险降低

里氏代换原则

这个原则是关于继承的

继承的优点
代码共享,每个子类都拥有父类的方法和属性
提高代码的扩展性,子类可以异于父类
继承的缺点
侵入性,子类必须有父类的所有属性与方法
增强了耦合性,从修改的角度来看,如果要修改父类,必须要考虑子类的修改

里氏替换用原则就是为了克服继承的缺点,如何实现它?

1. 子类的所有方法必须在父类声明,或者说子类必须实现父类中声明的所有方法.如此这般,在修改父类时.就可以降低难度
2. 为了实现里氏原则,可以把父类设计为抽象类或者接口,添加新功能时,直接实现一个新的子类就好
3. 在JAVA的编译阶段,编辑器会通过语法检查程序是否符合里氏代换原则

依赖倒转原则

高层依赖低层模块×
高底层模块依赖其抽象√

抽象依赖细节×
细节依赖抽象√

依赖层级:模块->抽象->细节

要面向接口编程,不要面向实现编程
也就是说把变量类型声明,参数类型声明,方法返回类型声明,数据类型的转换放到抽象类与接口中
这样的话,如果发生修改,只需要扩展抽象层,然后添加具体的实现类,实现了开闭原则

那么如何实现它?针对抽象层编程,具体的类需要通过依赖注入的方式,常用的有三种方式

1. 构造注入:通过构造函数出入具体类的对象
2. setter注入:通过setter方法进行注入
3. 接口注入:在定义时使用抽象类型,在实际运行时传入具体类型的对象,用子类对象覆盖父类对象

它的作用(好处)

1. 降低类之间的耦合
2. 提高系统稳定性
3. 减少并行开发的风险
4. 提高可读与可维护

具体的实现手段

1. 每个类尽可能提供接口或者抽象类,或者二者兼备
2. 变量的声明类型尽量是接口或者抽象类
3. 任何类都不应该从具体类派生
4. 使用继承时尽量遵守里氏替换原则

接口隔离原则

这里的接口是指产品设计或者编程思维中的接口,它描述的是按照合理的颗粒度将接口定义出来的原则.

单一职责与接口隔离的对比:前者重在类的层面职责的规划,而后者针对更上一层的接口之间互不依赖

它的优点:

1. 通过拆分复杂的接口,防止未来的更改在更大范围的代码之间扩散

具体实现:

1. 接口定义虽然要足够小,但是得有限度

2. 提高内聚,减少接口对外的依赖,让接口用少的方法完成多的事情

3. 迪米特法则
   又称最少知识原则,如果两个软件实体无须直接通信,那么就不应该发生直接的项目调用,也就是说,用一个合理的第三方(如果第三方太多会降低效率)帮助实体相互通信可以有效降低实体之间的耦合程度

它的优点:

1. 降低了类之间的耦合,提高了模块的相对独立性
2. 从上一条又延伸出,它提高了类的可复用率和系统的扩展性

具体实现方法:
两个角度:依赖者-只依赖改依赖的对象;被依赖者-只暴露该暴露的方法

1. 在类的划分上,应该创建弱耦合的类,以达到可复用的目标
2. 在类的结构设计上,尽量降低类成员的访问权限
3. 在类的设计上,优先考虑这个类设为不变类
4. 引用其他类时,将次数降到最低
5. 只通过get,set访问类属性

开闭原则

软件可以通过拓展的方式实现后续的修改,而不是编辑原有代码
毕竟软件生命周期中花费最多的就是后期修改与维护

它的地位:其他五个原则都是它的具体指导思想与工具

为了实现它,需要对整个系统进行抽象化设计

1. 使用抽象(接口or抽象类)将一组未来可能变化的行为
2. 通过团队章程约束整个开发团队的规范
3. 封装变化,为未来的变化创建稳定的接口

它的优点无非是:提高复用性,提高维护性

Java设计模式的六大准则

原文：https://www.cnblogs.com/gobanana/p/15000157.html