少有人走的路勇哥注：
此为转贴，载于：https://zhuanlan.zhihu.com/p/133872816
这个某位软件经理的项目实践，放这里让诸君共勉。
控制反转和依赖反转是软件框架里面常见的设计方法，说起来容易，但使用起来很难，其根本原因在于场景的难识别。本文根据实际项目中的落地经验来谈一谈控制反转和依赖反转的相关技术。
重构背景
去年10月上旬，公司正式立项智能售货机（地铁站卖水的自助售卖机）项目，我被指定为该项目的技术经理，全权负责该产品的所有技术。
智能售货机的主要流程为：
整个流程大体上可分为四步：选择商品、支付、出货和售后服务。
由于公司的业务扩大，客户要求我们再做一台咖啡机，于是又成立了另外一个项目组，负责智能饮品机（类似于商场里面自助咖啡机）的开发。
流程大体上也可分为四步：选择商品、支付、出货和售后服务。
由于饮品机项目的技术经理另有安排，于是我接手该项目，了解到该项目的整体流程后，发现两个项目的流程是类似的，只有有限的几步是不一样的，让我陷入了沉思。
有必要安排两拨人来开发APP吗？
后台可以共用一套流程吗？
前端可以用一套代码来实现吗？
设计的反思
两个产品的相同点
支付方式和流程一样
售后服务一样
两个产品的不同点：
整体外观上不一样：售货机属于竖屏（商品种类多）、饮料机属于横屏（需要制作咖啡）
商品显示和选择不一样：售货机可以选择多件商品，饮料机只能一次选择一样，也就是显示界面不一样
出货方式不同：售货机直接掉货、饮料机需要先制作然后再出货
根据以上相同点和不同点，不难想到两种重构方式：
方式一：把支付和售后做成公用模块，其业务逻辑重用
方式二：整体做成一个框架，每个产品只实现不一样的地方
大部分人都会选择方式一，这样可以加快研发速度，毕竟有部分模块得到了重用，但人力并没有减少，还是需要那么多人，资源并没有被释放出来。在实际开发中，我们采用了方式二，前端开发可以释放出一个人，仅需要一个人就可以完成两个项目的开发与调试。之所以能做到，完全依赖于控制反转和依赖反转这两种思想。谈起控制反转和依赖反转，不得不提及依赖注入，因此本chat就来探讨一下这些思想的相关技术、使用方法及场景。
