使用了这么久依赖注入，鼓吹了这个久依赖注入，去年加入温哥华发展迅猛的一个财务云服务公司，居然发现我加入的这个项目居然完全没有使用依赖注入来构建项目。What！这都是9012了，感觉怎么回到了石器时代。刚开始觉得有点不可思议，可是某一天，脑子里咯噔一下，猛然发现原来我认为依赖注入是理所当然，因此更多时候是探究如何实现、如何应用，却未曾思考过依赖注入的本质是什么，为什么要依赖注入？因而有了写这么一篇文章的动机。
什么是依赖关系
依赖关系直白的说就是是调用关系或使用关系。
调用和使用是一个更广泛的词汇， 多用于模块与模块之间，系统与系统之间。当我们考虑模块的时候，特别是系统，自然而然就会认为是其构建和调用应当分离的，因为被调用的模块或系统太厚重了。当你要发送短信的时候， 不会自己构建个短信发送平台来，自然会直接调用第三方的接口。
然而，在小尺度上的开发，我们却是表现的很轻率：很随意就构建和使用其他的类，使本类看起来功能非常强大，甚至无所不包，曾几何这甚至是软件行业的一个发展方向，这样的类有一个响亮的名号Smart Object, 业务类不仅有业务逻辑，甚至读写数据库，RPC调用等等丰富功能都包含在内，一“类”开发，非常强大。当年这个Smart Object的流行度语现在AI有的一比。至今，还能在一些仍然存活的项目中看到Smart Object的遗迹。
作为整个行业的趋势，这种重量级的开发方式已经遏制，可是开发生活不只是第三方框架，我们80%的日常依旧是自己的代码自己的设计，我们自己的设计并没有从这个陷阱中走出来。
Tips： 设计是小尺度的架构，架构是大尺度的设计。
说了这么多， 让我们来做个小小的验证：现在打开你的项目，看看你的源代码，是不是充斥这中构建代码new ()。当然，不是所有的new语句都是问题，可是，想都不想就用new绝对是个问题。
那么，哪些new是问题，哪些new又不是问题，就是我接下来要说的依赖分析。
依赖分析
浅析更广泛的依赖关系
发布时部件依赖
依赖地狱是一个专有词，描述软件包对于库依赖混鲁昂造成的问题。
具体问题有： 过多依赖， 多重依赖，依赖冲突， 循环依赖。
Windows早期并没有很严谨的DLL版本管理机制，以致经常发生安装了某软件后，因为其覆盖了系统上原有的同一个DLL文件，而导致原有可运行的程序无法运行。但还原回原有的DLL文件之后，所新安装的软件就无法运行。若影响到系统所使用的重要DLL时也可能让系统容易死机甚至无法正常启动。
