设计原则

单一职责原则

• 一个类，只有一个引起它变化的原因。即单一职责。

优点：

1. 类的复杂性降低，实现什么职责都有明确的定义
2. 可读性提高
3. 可维护性提高
4. 变更引发的风险降低

注意：“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。生搬硬套会引起类的剧增，给维护带来很多麻烦，而且过分细分类的职责也会认为的增加系统的复杂度。

建议：接口务必做到单一职责，类尽量做到一个原因引发变化。

里氏替换原则

• 所有引用基类的地方必须能透明地使用其子类对象，反之则不行

里氏替换原则为良好的继承定义了一个规范，包含了4层含义：

1. 子类必须完全实现父类方法
2. 子类可以有自己的个性
3. 覆盖或实现父类方法时输入参数可以被放大(重载、不能反过来)
4. 复写或实现父类方法时输出结果可以被缩小

依赖倒置原则

• 高层模块不应该依赖低层模块，两者都应依赖其抽象，抽象不依赖细节，而细节依赖抽象（面向接口编程）
  ps:在java中，抽象指接口或抽象类

依赖倒置原则本质是通过抽象使各自模块间的实现彼此独立，不互相影响。目的是模块间松耦合。

需要做到：

1. 每个类尽量都有接口或抽象类，或者两者兼备
2. 变量的表面类型尽量是接口或者抽象类
3. 任何类都不应该从具体派生（个人认为也不绝对，一些POJO类还是可以接受的）
4. 尽量不要复写基类方法，会对稳定性产生一定影响
5. 结合里氏替换原则

好处：规避一些非技术因素引发的问题。项目越大需求的变化概率也大，通过依赖倒置原则对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。

追求：稳定性较高的设计，在周围环境频繁变化时，依然可以做到“我自岿然不动”。

接口隔离原则

• 实例接口：客户端不应该依赖它不需要的接口

• 类接口：类间的依赖关系应该建立在最小的接口上

概括：接口尽量细化，同时接口中的方法尽量少

要求：

1. 接口尽量细化(但不能违反单一职责)
2. 接口高内聚
3. 定制服务，只提供访问者需要的方法
4. 接口设计有限度，接口粒度小，灵活但意味着结构复杂，开发难度变高，需要根据经验和常识判断。

迪米特法则

• 一个类应该对其他的对象有最少的了解。即一个类应该对自己需要耦合或调用的类知道的最少。

核心观念就是类间解耦，弱耦合

栗子：

图片.png

开闭原则

• 一个软件实体，如类、模块和函数应该对外扩展开放，对修改关闭

• 开闭原则是面向对象设计的终极目标（精神领袖），其他设计原则都可以看做是开闭原则的实现（工具和方法）。

应该尽量通过拓展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化。
改变尽可能的少，就能防止风险的扩散。
这要求我们在设计时能够预知变化，考虑如果产生变化现今的架构能否轻松应对变化。要符合现有需求并能拥抱变化，才是一个优良架构。
但开闭原则只是一个理想目标不可能百分百做到，过于的去预知变化会产生过度设计，也许设计的东西压根不会被用到还徒增来复杂度。所以需要“重构”思想作为指导，“事不过三，三则重构”。