设计模式_30
# 作业
消息队列，作为观察者模式的的代表，极大程度地实现了解耦，也在很大程度上解决了资源有限时的高并发崩溃。
我认为API的使用也算是一种解耦吧，将客户端与服务端，将不同模块的服务可以高效配合，但不关心对方的实现。现在的web项目普遍使用了前后端分离的方式，其实在这之前还有一种混合(耦合)的方式，前后端的代码在一个仓库中，前端的细微修改要发布整个项目，极容易出错。

# 感受
我们现在技术，很大程度上解决了人脑解决不了的速度问题和复杂性问题，速度问题主要取决于硬件(只要代码不是特别糟)，复杂性问题就成了程序员的重大难题，因为它违反直觉，它的设计起来困难且更需要耐心。

另外，可以开始复习了。。。文中提到的原则有些已经记不清要点了。

实际上，在我们平时的开发中，解耦的思想到处可见，比如，Spring 中的 AOP 能实现业务与非业务代码的解耦，IOC 能实现对象的构造和使用的解耦。
除此之外，你还能想到哪些解耦的应用场景吗？
解耦是人类应对复杂性问题的有效手段,解耦的核心是拆分,横向可以拆分出不同的模块,纵向可以拆分出不同的工序,然后就有了人类的大分工协作,分工协作可以把大规模的人有效组织起来参与社会大生产,最终推动社会生产力的进步.
解耦场景如国家机器的运转,国务院有国防部/人民银行/财政部/审计署/农业部/保障部/卫生部/教育部/司法部/交通部/水力部/建设部/信息产业部/计委等不同部门组成,另外各个地方政府又有一套完整的组织体系共同组成中国的政府系统.各部各司其职,如人民银行负责货币政策的调整,财政部负责税收政策的调整等.
企业的组织运转也是解耦的,企业内部不同的职能部门,如计财部/人力部/技术部/市场部/运营部.
技术部又有不同的岗位,如产品经理/UI/开发/测试/运维.

打卡✔
在小公司的团队种 如果注释用英文怕是会被喷

看到有留言说 欠揍太长了 我不太赞同
越是想往刚处越要捡起基础
就算用了若干设计模式
基础的东西都搞不好有什么作用呢

打卡
1、如何判断代码是否需要解耦
直接衡量标准：画出模块与模块、类与类直接的依赖关系，如果依赖关系复杂则需要重构
间接标准：牵一发而动全身
2、如何进行解耦
1、封装和抽象（如linux的open函数）
2、增加中间层（可分阶段）
第一阶段：引入中间层，封装新接口。
第二阶段：新的模块开发基于新接口。
第三阶段：调用老接口的代码替换为新接口。
第四阶段：删除掉老的接口
3、模块化
4、利用设计原则和思想
1）单一职责原则
2）基于接口而非实现编程
3）依赖注入
4）多用组合少用继承
5）迪米特法则