第二周学习总结

架构师，就是让别人依赖你的代码，你开发的框架，别人要基于你的框架去开发东西，有问题要找你才能解决，这时你在公司的架构师的地位就奠定了。框架也可以不是完全由你开发的，但至少是你选型的，或者是主要的维护者。



什么是框架？什么是工具？

框架：定义了规范，别人是要基于框架进行编码才能实现具体功能；

工具：提供了具体功能，别人只需要调用就可以；

例如：junit是一个框架，我需要实现单元测试内的逻辑；log4j是一个工具，根据入参实现日志记录的功能。

设计模式的收获

设计模式、设计原则真的是一个值得反复琢磨的东西，初看设计模式第一感觉就是晦涩难懂，看是看完了，还是不知道怎么在代码中应用。不过每过一段时间，看看不同人对设计模式的理解，都会有新的收获。

OOD原则一：开/闭原则（OCP）

可以通过策略模式、观察者模式、适配器模式打断类之间的强关系，解耦。达到新增功能只新增代码不修改原有代码的目的；

OOD原则二：依赖倒置原则（DIP）

依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象



主要分辨接口是由谁定义的。由高层模块定义接口，底层模块仅实现，叫做依赖倒置。但是如果是由底层定义接口、底层实现，这种就不叫依赖倒置。

举一个形象，但可能不太恰当的例子：

1、service层定义接口，由controller调用，这个属于高层依赖低层；

2、controller定义接口，由service层实现，这个就是高层不依赖低层，是符合依赖倒置原则。

这个原则在做业务功能开发的时候，可能不太适用，因为分层架构强调的就是单向依赖。

在做系统框架的时候，理解比较深刻点。在做框架时，高层就是我们定义的通用业务规则，低层就是项目的具体实现细节。框架约束了实现的范围，具体细节依赖框架实现，框架不受具体实现细节的影响。

OOD原则三：里氏替换原则（LSP）

子类的访问控制不能比父类更加严格

OOD原则四：单一职责原则（SRP）

这个比较好理解：两个不太相关的逻辑不要放到一个类里面。PS：不过通常做业务的时候，当业务逻辑变大时才拆，逻辑简单的时候，拆开反而增加类间关系的复杂度。

OOD原则五：接口隔离原则（ISP）

推荐通过适配器模式，解决胖接口的问题。