控制反转思想的理解

对于控制反转的一些理解

聊一聊“层”

在开发的很多框架里总有一层又一层的结构，让人眼花缭乱，但与此同时，也流传着一个笑话——如果嫌架构耦合度高，代码复杂，那就再加一层，没有什么事是加一层解决不了了的，如果有，那就再加一层。

这样的说法也并非毫无道理，但这里的“层”的意义有点抽象，广泛点来讲，它可以理解为一层平面，承载了各种来自上层的需求，各种数据的转发，同时这一层的各个文件也对下一层进行着各种对接，承上启下，上看下只能看到这一层，透明且隔离，很大一部分程度降低了耦合度，狭义点来说，它可以概念上理解为一个小个体，类似于房产中介，但是它又被放大了无数倍，这个概念运用于整体架构的各个核心细节和方面上，从这两者出发构成了“层”的概念。

进入正题——什么是 IoC

好了，我们现在说完了我对层的理解，那我们来谈层与层之间的关系，这里的关系很广泛，我们拿生活中的例子打比方，譬如食客与饭菜，租客与房子。

食客想要吃菜，那食客一个个地去做，想吃一个就自己做一个，一下来100个食客，如果一人一道菜，那就是一百个人来亲自做一百道菜，岂不麻烦？不急，我们拿出我们的法宝——“层”，我们加一层“厨师”概念，这样一来，来一个食客，对厨师说我要啥，厨师做了，就给你上啥菜，请注意这里的控制权的变化，从一开始的食客自己做菜，亲力亲为，到厨师做菜，食客翘着二郎腿哼着歌，只管厨师上了菜，自己舒舒服服地来吃，这里的控制权从食客自己手上到了厨师的手上，用计算机术语讲，从控制正转变成了控制反转IoC，创建和查找依赖对象的控制权进行了对调，控制权到了IoC容器——厨师手上。

租客和房子也是同理，租客租房子，一个一个地去根据需求租，但是我们加入一层——房产中介，从自己去租，到了房产中介帮我们去租，对房子的控制权发生了变化，控制正转变成了控制反转。

一点拓展——DI的概念

这样一来，有了厨师，房产中介这样的角色在，那就方便了很多，对于厨师，你对他的要求——我要喝从喜马拉雅山顶上融的雪水加悬崖边上生长的番茄以及每天啄五百次的老母鸡产的鸡蛋做的西红柿蛋汤，你不用管怎么来，你只负责喝就行了，这样一来，水，番茄，鸡蛋这几个数据，我们称为种子——bean，我们放进厨师——IoC容器里，然后拿出了西红柿蛋汤——对象，美滋滋地喝完了，贯穿于整个过程的理念，就是控制反转IoC——厨师做菜，依赖注入DI——种子放进容器里，很明显的是，依赖注入是实现控制反转的手段，IoC是bean的注册，DI是bean的初始化。

一些吐槽

这就是对于控制反转的一些理解，其实个人感觉平时日常生活和一些鸡汤道理中也不乏这种理念的存在，我自己懒得一个个地对接，耦合度太高，太麻烦，我把责任和一部份权力放给下面的一层，要用的时候拿不到正确的东西——也就是报错了，不会在我身上找问题，而是去负责的那一层一点点地看是哪里出了毛病，这样一层层分割开来，一层层追责，是不是感觉有点熟悉啊哈哈（/手动狗头）