设计模式原则理解

什么是设计模式

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。

六大原则

单一职责原则，里氏替换原则，依赖倒置原则，接口隔离原则，迪米特法则，开闭原则

单一职责原则

尽量一个类只实现一种功能，避免出现假如有多个功能后更改其中一个然后影响其他的情况

里氏替换原则

子类继承父类后，尽量避免重写父类的方法，继承的4大原则

依赖倒置原则

1. 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
2. 接口或抽象类不依赖实现类
3. 实现类依赖接口或抽象类

类A依赖类B，要想类A依赖类C竟然要改类A的代码
类A中调用类B，这样要想换一个就得改A中代码
使用接口 ，类B，类C都用接口实现，然后类A中调用接口这样实现的时候想用谁就new 谁的对象就可以了
使用场景

1. 构造函数传递依赖对象
2. Setter方法传递依赖对象
3. 接口声明依赖对象

接口隔离原则

1. 一个接口只服务于一个子模块或业务逻辑模块
2. 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口高可用
3. 已经被污染的接口，尽量去修改，若风险大，就用适配器模式进行转化
4. 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，深如了解业务逻辑，最好的接口设计就出自自己的双手

避免接口臃肿，导致实现类有多余空余的抽象方法没有用
利用可以多实现接口的优点，尽量多来几个接口也不要浪费抽象方法

迪米特法则

一个对象应该对其他对象保持最少的了解
降低类之间的耦合，避免功能在其他类中实现导致一个类改变时其他类也得改变
你的内部有多复杂（那么多的public方法）都和我没关系，我就调用我需要的其他的不管我的事

开闭原则

一个软件实体如类，模块函数，应该对扩展开放，对修改关闭
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化

1. 修改接口
2. 修改实现类
3. 通过扩展实现变化