原来就了解过IOC控制反转的设计思想，也看过一些文章，总觉得自己好像都看得懂，也知道在讲什么，知道其能很好的解耦和，却隐隐约约又感觉自己好像还差了点什么。这次有点小运气，在写自己的迷你框架的时候，写到中途突然有种或豁然开朗的感觉，这里就次记录一下。
先说一下最开始的想法，假设有一天你需要输出各式各样的东西（种类繁多），比如各式各样的操作信息、教程、漂亮的html静态页面、以及各式各样的日志等等等等，如果都堆到一个类里面，显然不利于输出信息的分类，影响代码可读性，更不利于维护。这里我打算是写一个输出的类，比如我想在Filter中输出一个权限不足的html页面字符串(有样式)，我希望以这样的方式调用：String html_noAuthority = MyFormat.forType().html().problem().noAuthority().in("xxxProblem has encountered").out() ，如果是输出做某件事成功，则以这样的方式调用：MyFormat.forType().html().success().out() 或者 MyFormat.forType().html().success().in("register succeed").out()
最开始是这样写的： 以MyFormat.forType().html().problem().noAuthority()的调用为例
这样写确实是可以实现，但是其坏处也显而易见，那就是写的太死，耦合度太高了，从上面链式的调用中也可以看到，我每一个return的类都是指定的自己的实现类，设想假如别人（小红）想用你的东西，他觉得你其他的输出类都挺好，就是这个NoAuthority实现类的样式写的太丑了，别人想用他自己的NoAuthority_Beautiful实现类来代替你的类，但是以jar包形式的源码一般又是不可以修改的，即使可以修改，在业务变动的情况下需要频繁地修改别人的源码。显然，如果这么写肯定不合理。
那怎么办呢？有人想，直接在这些基础上来一个函数重载，如果想用自己的实现类就传一个自己的class进来，比如：
如果是这样，好，那完蛋了。因为很显然，返回值是接口，这么写就相当于没写，如果硬是要这么写，那只能在该类的接口中多加一个重在函数，但是这样，好，那也完蛋了（大量的实现类要修改，和代码重复）。如果只保留上图中第二个函数，虽然可以可以满足小红的需求，但是每次都要传一个Class进来，使得使用起来极其不爽（显得多此一举），同时try catch还会影响一点点速度，更重要的是，在每一个实现了这种带Class参数的接口的类中，每一个函数都要try catch ，显然冗余了大量重复且不可观的代码，于是乎三个字：完蛋了
所以看到这里，在没有IOC的情况下，整个小体系给人感觉就是一潭死水，没有生机也不灵动
那使用了IOC思想后会怎样呢？
写到这想必已经开始明了了，我们只需要将noAuthority该实现类的对象提出来 (即这里定义的 ThiTierType noAuthority引用)，并对其提供一个set方法，然后，，，然后通过IOC容器配置相关bean，就可以对该引用疯狂地赋值了！原来是写死的NoAuthority实现类，现在管你想替换成什么NoAuthority_Beautiful还是什么NoAuthority_BeautifulPlus或是什么NoAuthority_BeautifulSuperPlus都可以！
那么究竟是哪个环节一下子就轻松地打破了这滩死水呢？关键其实就是看究竟是谁创建出了NoAuthority类的对象
在传统的方式中，是noAuthority函数主动地去创建了NoAuthority类对象给别人用，而在IOC思想中，是IOC容器创建了NoAuthority类对象然后给noAuthority函数用（关系被反转了）。 那为什么这种反转能带来如此强大的灵活性和多样性呢？
我们可以这样想，传统方式中是代码指定创建什么类，可代码是死的，代码指定创建什么就只能创建什么。在IOC中是人指定创建什么类(即配置)，代码是死，但人是活的，你想换成什么就配置什么就可以了。
其实仔细想一下最基本的面向对象思想也能想明白，为了解耦和，一个类或者一个函数，更应该专注于一件事情，就像一个伐木工人伐木，伐木工人更希望你给他一个斧子，而不是他自己去建造一把斧子，然后再去伐木，前者的耦合度是一(伐木)，后者的耦合度是二（造斧头+伐木） 。如果对应到代码就是一个伐木工人类，内部有一个斧子引用，有一个伐木方法，这个伐木工人（类）更希望他在伐木前（函数调用）就把斧子已经做好了（函数调用前被创建而不是函数过程中再创建）
而回到我上面的代码中，也正是因为IOC的思想，别人不仅能用我写的类，不想用了还能替换成他自己的类，这其实也就无形中降低了耦合度，增加了多样性