首先恭喜守宏同学找到了自己心仪的工作，入职的事情终于尘埃落定，也算是一个新的开始吧。和守宏聊天的时候也说了很多有关工作的事情，畅想了以后美好的未来，也想到了今后的种种困难。不说别的就是单单在北京住房这一项就够任何一个职场上的人忙上好几年的。英国天气无常，所以英国人寒暄的时候常常谈论天气；北京人居无定所，所以在北京上班的朋友们大可以在寒暄的时候谈论租房;)。
“哎，你在哪租的房子？”
“我在西二旗那边，挺便宜的……”
“嗨，我之前在那边住过……”
很多在北京工作的朋友第一要考虑的就是住宿的问题。没办法“衣食住行”里面其他的都还好说，唯独“住”这件事在帝还是一个比较特殊的问题。也问过大多数在北京的朋友，他们普遍的反应就是想省事就找中介，想省钱就自己找。不过现在好多了大家大部分都是在网上直接找到房东，然后商量价钱进而签合同再然后就是入住了。不禁感叹，信息化发展了就是不一样，真的能感觉到有一台能上网的终端（无论是计算机还是手机）就拥有了世界。
想必读到这里已经有些人开始骂街了，这哪是Spring IOC原理解析啊!这纯属是扯淡啊!!!上面铺垫完毕，下面进入正题。
生活中的Spring IOC解析
说到租房子这件事的时候猛然间就想到了Spring，类似58同城之类的发布信息的网站不就是Spring里面的容器么。网站上有很多别人提供的可以选择的房子（Bean），你所需要做的就是在没有租房子之前想好自己的要求，比如得能洗澡，能做饭，冬暖夏凉，距离上班的地方近（这俨然就是一个定义接口的过程），然后去网上检索寻找合适自己的房子，前提是房东已经主动的将房源信息公布到网上（公布房源信息的过程就是将Bean放入容器的过程，我们寻找房子的过程就类似于Spring中注入的过程，至于是直接注入还是JNDI注入，道理都是一样的，具体方式不一样而已）。找到房子了也就是注入成功了，找不到那只能抛出异常喽。宗旨就是：只要条件满足，房子可以随便换（只要实现了接口，具体注入哪个实现类无关紧要）
基于有向图的Spring IOC解析
从守宏提到聊面试题当中还是学到一些比较有意思的东西，比如：Spring的数学原理----有向图。且不说这个论点对与不对，单就Spring和有向图这两个与“信息与计算科学”专业息息相关的知识点来看，这个论题也是值得自己好好想想的，下面就说说笔者对这句话的理解。
为了方便叙述我们把Spring管理的每一个Bean当做一个节点（假设有N个Bean，那么就有N个节点），于是这些Bean加上相互之间表示调用关系的有向边就组成了一个有向图。毫无疑问，有向图的边越多那么平均来说每个顶点之间的耦合度就越大，最大的情况为完全有向图，即任何两个节点之间都有两条有向边，此时每个顶点的度为2（N-1），也就是说每个Bean与其他的N-1个Bean有耦合，而且还是双向耦合。如下图所示（这里N=3）
众所周知，编程的过程中我们总是强调高内聚、低耦合，要想达到完全的无耦合（如下图）是不可能的。所以最优情况是保持一种松耦合的状态，即在保证实现功能的前提下尽量减少类之间的耦合。我们可以利用接口达到这一目的，通过不同的实现类让调用方对具体实现不再关心，从而达到松耦合的目的。
但是无论耦合多么“松散”具体的实现类还是需要new出来的，于是就得考虑这个new的过程应该放在哪里才是最合适的。如果在每个Bean中都去new这个Bean需要的其他Bean，那么耦合的程度又回到了第一幅图的情况，那是没有意义的。聪明的读者一定想到了如何解决这个问题：找一个中间人，在中间人那里实现new的过程，然后把new好的实例传递给需要这个实例的对象。这样的话一切问题就迎刃而解了，最终的效果如图所示
上图也就是Spring的数学描述，图中很清晰的表明了在使用Spring之后，任意两个节点（Bean）之间的有向线段变成了0（确切的说不完全是0，因为任意两个节点之间还是可以通过容器连接的），唯一和这些Bean有关系的是容器（无论谁需要什么东西都去找容器，尽量避免两个Bean之间直接打交道）也正因为如此Spring才达到了解耦的目的。
所以说，上面提到的“Spring的数学原理是根据有向图而来”这句话是有一定道理的。换个角度去看计算机，从生活，数学或者其他方面也许能把计算机看的更清楚。
