设计模式之美

01 为什么要尽早地学习并掌握设计模式相关知识

我理解的设计模式主要功能是：解耦和扩展

02 从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？

思从深而行从简，真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本质区别之一。

03 面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？

贫血模型和充血模型

08 | 理论五：接口 vs 抽象类的区别？如何用普通的类模拟抽象类和接口？

抽象：表示一种 is-a 的关系，为了解决代码复用问题；这是一种自下而上的设计思路，现有子类代码重复复，再提取；

接口：表示一种 has-a 的关系，为了解决抽象而非代码复用问题；这是一种自上而下的设计思路，先设计接口，再去考虑具体的实现；

10 | 理论七：为何说要多用组合少用继承？如何决定该用组合还是继承？

继承最大问题：

继承层次过深，继承关系过于复杂带来的代码可读性和可维护性。

比如“鸟”：会不会飞，会不会叫，会不会下蛋

但：组合并不是完美的，继承也并非一无是处

12 | 实战一（下）：如何利用基于充血模型的 DDD 开发一个虚拟钱包系统？

Repository 的 Entity，即便它被设计成贫血模型，违反面向对象编程的封装特性，但 Entity 的生命周期是有限的。一般，它传递到 Service 后，就会转化成 Bo 或者 Domain 来继续后面的业务逻辑。其生命周期到此就结束了，并不会被到处任意修改。Controller 层的 Vo 单纯作为一种 DTO，亦是如此。

13 | 实战二（上）：如何对接口鉴权这样一个功能开发做面向对象分析？

OAuth：调用方将接口的 URL 和 Apple、密码拼接在一起，然后进行加密，生成一个 token。

OAuth2？

17 | 理论三：里式替换（LSP）跟多态有何区别？哪些代码违背了 LSP？

里式替换原则（design by contract，按照协议来设计）：父类定义了函数的“约定（或协议）”，子类可以改变函数的实现逻辑，但不能改变函数原有的“约定”。如对函数输入、输出、异常的约定，注释中所罗列的特殊说明等。