总结2
软件设计的臭味，即一些不好的地方
软件设计的最终目的是达到 "强内聚、松耦合"，以使软件 ：
- 易扩展，增加功能
- 更简单，容易理解，不复杂看不懂
- 更强壮，不容易出错
- 可移植，可以多种环境运行，比如jdbc的库
不好的软件，会发出如下的"臭味" ：
- 不易改变
僵硬，脆弱，改一个地方，影响其他地方 - 晦涩难懂
- 容易出错
- 不可移植
- 过度设计
对象 和 面向对象
对象
对象具有 状态 行为 标识 三个特性
- 状态
每个对象有自己的数据 - 行为
每个对象可以产生行为 - 标识
每个对象都区别于其他对象，比如 唯一的地址区分
面向对象编程三要素
封装
继承
多台
框架 和 库工具
框架 ：
是用来实现某一类应用的结构性程序，是对某一类架构方案的可复用设计与实现
框架只是提供了一个架子，里面具体的功能需要自己提供
是需要向里面填充东西的，
框架就像一个房子，有客厅、卧室、卫生间、厨房，但是，具体什么样，最终的功能什么样，还得自己实现
框架，调用你的东西，你并不需要调用框架的东西
比如说插件，插件就是一个框架
库，就是一个工具，直接使用即可，库提供了自己的功能，用户只是需要使用它的功能
架构师使用框架来保证架构的落地
注意，架构师，应该多关注框架，多关注框架的思想
架构师使用库工具来提高开发效率
OOD原则，即 Object-Oriented Design，面向对象设计的原则
包括 SOLID 原则，一共 六个原则，其中有两个 L开头的原则
S 单一职责原则 Single Responsibility Principle SRP
- 又被成为 "内聚性原则", 一个模块的组成元素之间的功能相关性
- 将它与引起一个模块改变的作用力相连，就形成如下描述：一个类，只能有一个引起它变化的原因
一个类，只有一个引起它变化的原因
什么意思？
什么是职责？
暂时只能理解为行为，对象三要素中的行为，行为功能是单一的
O 开/闭原则 open/close principle OCP
- 对于扩展是开放的
- 对于更改时封闭的
这个歌 扩展 和 更改 指的是更改这个 类，而不是类实例中的数据
比如加个字段，删个字段，加个方法等等
L 里氏替换原则 Liskov替换原则 LSP
-
或对每个类型 T1 的对象 o1，都存在一个类型T2的对象o2，使得在所有针对T2编写的程序 P 中，用 o1 替换 o2 后，程序 P 的行为功能不变，则 T1 是 T2 的子类型
-
简而言之：子类型(subtype) 必须能够替换掉他们的基类型(base type)
Is-A 的问题：
Is-A 是关于对象的行为的
对象包含 标识、状态、行为，只有 行为是相同的，其他是不同的
只有行为相同，才是 Is-A，才能符合 Liskov替换原则
L 迪米特法则 Law of Demeter
只和亲密的人交谈，不和陌生人说话
也就是说，两个软件实体，如果不应该发生直接的相互调用，就不应该相互调用，可以通过第三方交互
I 接口分离原则 Interface Segregation Principle ISP
- 不应该强迫客户程序依赖它们不需要的方法
SRP 指出如何设计一个类
ISP 指出如何设计一个接口
D 依赖倒置原则 Dependency Inversion Priciple DIP
- 高层模块，不依赖低层模块，而是大家都依赖于抽象
- 抽象不能依赖实现，而是实现依赖抽象
怎么理解
高层、低层模块，可以按数据流向来分析，数据来源是高层，数据接收者是低层，也可以按照调用顺序来区分，调用者高层，被调用者低层
举个例子，
通常而言，遇到的情况时 高层模块 A -> 调用低层模块 B 提供的接口的方法。
比如各种各样的库，都是这样，提供一个接口，然后用户调用这个接口对象的方法
再比如，controller 调用 service 接口，去操作数据库等等
现在，需要倒置过来，即 A 提供一个接口，然后在 A 中，A 主动的调用这个接口，然后，低层 B 去实现 A中的接口，并且 A 持有 B 对象实现的一个抽象接口，这样的话，A 就可以自动的调用B实现的功能。也就是说，B现在依赖的是高层A提供的接口，而不是A去依赖B了
A : 接口 IA，IA 的方法 funcA
B : implements IA
然后 A 持有 B 实现的 IA，这样的话，A 就可以 调用 IA.funcA()
A 不依赖 B，B也不依赖A，双方都只依赖 IA
另外的常见的例子，比如插件，软件提供了插件接口，用户可以实现各种功能的插件模块，软件会调用这个插件，以提供插件的功能
DIP 倒置了什么?
- 模块和包的依赖关系
如上面例子，倒置后，就不是 A 要持有 对象B了，而是 A 只知道接口 IA - 开发顺序和职责
倒置后，低层 B的开发，只能依赖 A 提供的接口了，也就是开发顺序也倒置了。而不是以前的 A 等着 B 提供一个接口来调用，这样，职责也就倒置了
A 占据主导地位
软件的层次化：
- 高层决定低层
因为 高层框架制定了接口规则，肯定高层决定了低层应该怎么去开发 - 高层被重用
这就理所当然了
框架的核心 ： 好莱坞规则 ： Don't call me, I'll call you.
框架倒转了层次依赖关系
