架构师训练营第二周总结

反应式编程框架：



怎么解决线程阻塞导致的超时问题？

线程的复用，线程不进入service代码，把request交给service。在service相互调用的时候使用akka容器。数据库连接（这个反应式编程我真是听不懂，从头到尾没有接受到任何有用的信息，老师对着PPT讲，说那么快，听了好几遍都没有什么印象，很多东西没有交代清楚）



这周老师讲了一下他两个项目的经历。具体就是他是如何成长为架构师的。我个人认为这只是两个故事而已。对大众没有什么参考价值，每个人的情况都不一样，在人成长的路上充满了随机性。很多时候，并不是做了充分的准备和努力就可以把一件事情做出。成为架构师对老师来说是水到渠成的事情，但是对大多数人来说就是一个很难逾越的门槛。



面向对象编程与面向对象分析：利用多态进行编程，而不是使用面向对象编程语言



如果让别人依赖于你写的代码，你需要提供一个框架。



不同领域的框架：

1. Windows的MFC框架

2. Java GUI的AWT框架

3. 著名开源框架：Spring mybatis

4. web服务框架



第二课老师讲了软件设计的五个原则



单一职责原则（SRP）

就一个类而言，应该仅有一个引起它变化的原因

为什么要把不同的职责分到单独的类中呢，因为每一个职责都是一个变化的轴线。当需求变化时，该变化会反应为类的职责的变化。如果一个类承担了多余一个的职责，那么引起它变化的原因就会有多个。如果一个类承担的职责过多，就等于把这些职责耦合在了以一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

开闭原则（OCP）



软件的实体应该是可以扩展的，但是不可以修改。

OCP建议我们应该对系统进行重构，这样以后对系统在进行改动时，就不会导致更多的修改。如果正确地应用OCP，那么以后再进行同样的改动时，就只需要添加新的代码，而不必改动已经正常运行的代码。



遵循开闭原则设计出的模块具有两个主要的特征：

1.对于扩展开放意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展。使其具有满足那些改变的新行为。

2.对于更改是封闭的，在进行模块行为扩展时，不必改动模块的源代码或者二进制代码。

这两个特征好像是互相矛盾的。扩展模块行为的通常方式就是修改该模块的源代码。不允许修改的模块常常都被认为是具有固定的行为，怎样才能在不改动源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的抽象功能呢？关键是抽象

创建出固定却能够描述一组任意个可能行为的抽象体。这个抽象体就是抽象基类。而这一组任意个可能的行为则表现为可能的派生类。

模块可以操作一个抽象体，由于模块依赖于一个固定的抽象体，所以它对于更改可以是关闭的。同事，通过从这个抽象体派生，也可以扩展此模块的行为。



李氏替换原则（LSP）

子类型必须能够替换掉它们的基类型

依赖倒置原则（DIP）

a. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。b.抽象不应该依赖于细节。细节应该依赖于抽象。



传统的软件开发方法，比如结构化分析和设计，总是倾向于高层模块依赖于低层模块，策略依赖于细节的软件结构，这意味着低层模块的改动会直接影响到高层模块，从而迫使它一次做出改动。

实际上，应该是高层的策略设置模块去影响低层的细节实现模块。包含高层业务规则的模块应该优先并独立于包含实现细节的模块。无论如何高层模块都不应该依赖于低层模块。我们更希望重用的是高层的策略设置模块。如果高层模块独立于低层模块，那么高层模块就可以非常容易的被重用。该原则是设计框架的核心原则。



接口隔离原则（ISP）



不应该强迫客户依赖于它们不用的方法。

如果强迫客户程序依赖于那些它们不使用的方法，那么这些客户程序就面临着由于这些未使用方法的改变所带来的变更。这无意中呆滞了所以的客户程序之间的耦合。