架构简洁之道-设计原则
设计原则（SOLID）
SOLID原则主要作用就是告诉我们如何将数据和函数组合成类，以及如何将这些链接起来成为程序。
软件构建中层结构的主要目标
- 使软件可以容忍被改动
- 使软件更容易被理解
- 构建可在多个软件系统中复用的组件
SOLID
- SRP：单一职责原则
- OCP：开闭原则
- LSP：里式替换原则
- LSP：接口隔离原则
- DIP：依赖反转原则
SRP 单一职责原则
原则：任何一个软件模块（源代码文件）都应该只对某一类行为者负责。
主要讨论的是函数和类之间的关系，会以不同的形式出现。
主要是负责类和函数的组合
OCP 开闭原则
原则：设计良好的计算机软件应该易于扩展，同时抗拒修改。
将代码的修改量降至最小：先将满足不同需求的代码分组SRP, 然后再来调整这些分组之间的依赖关系DIP
如果A组件不想被B组件上发生的修改所影响，那么就应该让B组件依赖于A组件
- 依赖方向控制
- 信息隐藏
主要是负责类之间的指向关系
LSP 里氏替换原则
原则：这里需要的是一种可替换性:如果对于每个类型是 S 的对象 o1 都存在一个类型为 T 的对象 o2, 能使操作 T 类型的程序 P 在用 o2 替换 o1 时行为保持不变，我们就可以将 S 称为 T 的子类型。
负责类的继承，泛化实现
ISP 接口隔离原则
原则：任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
编程语言之间的关系：而正是这些语句带来了源代码之间的依赖关系，这也就导致了某些模块需要被重新编译和重新部署。这就是动态类型语言要比静态类型语言更灵活、稠合度更松的原因。
软件设计：框架之间的依赖关系
DIP 依赖反转原则
原则：如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。我们主要应该关注的是软件系统内部那些会经常变动的 (volatile) 具体实现模块，这些模块是不停开发的，也就会经常出现变更
编码守则
- 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。
- 不要在具体实现类上创建衍生类。
- 不要覆盖 (override)包含具体实现的函数。
- 应避免在代码中写入与任何具体实现相关的名字,或者是其他容易变动的事物的名字。
依赖守则： 而跨越边界的、朝向抽象层的单向依赖关系则会成为一个设计守则
抽象接口，易变的实现隔离。从而可以减少修改。（架构边界）
主要是负责 组织原则