通过多种设计模式(creational,structural, and behavioral)，理解各种模式， 并使用go来实现
设计模式是软件工程中重复出现问题的一种解决方案， 她是思想上的指导(或者是模板)，并不是具体落地的方案。
学习设计模式的目的：
- 再一次遇到出现的问题，心中知道用哪种对策好
- 和同事/利益相关者交流时，便于交流
设计模式的分类：
- 构造型
- 结构型
- 行为型
设计原则需要考虑两方面：
- 责任划分，每个类的职责是什么
- 依赖管理，这个类依赖哪些类，她们之间的约束关系是什么样的
对于底层面向对象的设计来说，遵循5个原则即可，solid
- S, Single Responsibility Principle
单一责任原则，一个类只有一个责任
同样，package的设计也要遵循这个原则 - O, Open/Closed Principle
开闭原则，对一个类来说，应该是扩展她的行为，而不是修改
spring框架就是典型
适用地方是运算逻辑、业务逻辑 - L, Liskov Substitution Principle
里氏替换原则, 任何基类出现的地方，子类都可以进行替换
和开闭原则稍有不同，任何子类都可以使用基类提供的接口
在go中，不存在其他语言中的继承，所以这条原则并不强调
反而在接口设计中，里式替换原则依然可以给我们指导 - I, Interface Segregation Principle
接口隔离原则，使用多个专门的接口比单个总接口要好
防止了接口污染
客户端不应该依赖她不需要的接口 - D, Dependency Inversion Principle
依赖倒置原则，依赖抽象，而非具体具体实现
降低耦合度
高层次不应该依赖低层次，她们都应该依赖抽象
抽象不应该依赖具体细节，反而具体细节应该依赖抽象
对应到go中，是下面两句：
1.每个packege都应该是通过接口来暴露功能，而不是具体实现
2.当package有依赖时，依赖应该作为一个参数
安全有效地创建对象，client对对象的使用和对象的创建实现分离
为啥要分离：
- client只需要消费对象即可，不需要为创建负责
这样client在使用对象时，不用关心对象如何创建、对象怎么创建的， client只需要调用对象暴露的接口即可。
对象创建不那么顺利的场景：
- 可能会有很多业务规则需要很多参数或属性
- 可能需要提高效率
- 创建对象时保证幂等性和线程安全
- 构造参数过多
builder设计模式，可以让我们把复杂的构造分层多个方面， 最后把所有的方面组合起来，就是我们需要的对象。
单例会增加组件之间的耦合度，所以尽量少用
用于描述对象之间的关系，简化设计
将不兼容的变成兼容
对象适配和类适配
- 抽象和实现解耦
- 接口层次和实现层次分两条线
多个对象之间的交流, 增加交互之间的扩展性,有些设计模式关注于对象之间的低耦合， 有些设计模式关注于对象交互的内部状态
对象表示的是一个请求，或动作，当然也包括了一些信息。
对象表示的是一个请求或是动作，命令模式的组成：
- command接口，封装多个要执行的操作，抽象类
- command实现类
- 调用者
接受者有很多，是一个链式，收到一个命令， 第一个接受者会查看是否能处理，如果不能就传递给下一个。
在两个对象之间添加一个第三方(中介)， 这样两个对象就是低耦合的
对象状态的捕获和存储，以及平滑的恢复
运行替换算法