迪米特法则/最小知识原则
迪米特法则的英文翻译是：Law of Demeter （LOD）
不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）
如何理解高内聚，低耦合
这是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计，“低耦合”用来指导类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖的类的代码改动.
分层的重要性
分层能应对系统复杂性，将代码水平方向基于业务来做拆分叫做模块化，垂直方向基于流程来做拆分，就是分层
BO，VO，Entity存在的意义是什么
之前提到的Controller，Service，Repository三层，每层都会定义数据对象，分别是VO（View Object） BO（Business Object），Entity，在开发中，可能存在大量的重复字段，甚至三者包含的字段完全一样，我们经常需要重复定义三个几乎一样的类，显然是一种重复劳动
代码重构的意义
为什么要重构，重构是时刻保障代码质量的一个极其有效的手段，不至于让代码腐化到无可救药的地步。项目在演进，代码不停在堆砌，如果没有认为代码的质量负责任，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。
优秀的代码或架构不是一开始就完全设计好的，就像优秀的公司和产品也都是迭代出现的。重构是避免过度设计的有效手段，在我们维护代码的过程中，真正遇到问题的时候，再对代码进行重构，能有效避免前期投入太对时间做过度的设计。
什么时候重构
重构的手段有：分层，模块化，解耦，抽象可复用组件等等。这类重构的工具就是我们学习过的设计思想，原则和模式
这类重构设计的代码改动会比较多，影响面会比较大，所以难度也较大，好事会比较长，引入bug的封信啊也相对比较大
重构策略是持续重构，，可以看项目中有哪些写的不够好的，可以优化的代码，主动去重构一下。
