在写《jQuery Ajax的封装》的时候，突然想到一些东西，于是就试着写下来……
控制反转
学习Laravel时，不可避免地一定要研究“控制反转”。
这里并不详细介绍“控制反转”，只是简单阐述一些其主要思想。
控制反转，是一种编程思想，通过“依赖注入”和“依赖查找”实现依赖倒置。本来一个实体，其控制权主要在其所依赖的其他实体身上，如果反转了这种关系，那么控制权就回到实体自己身上，实际上就是减弱对其他实体的依赖性（就是解耦吧）。
控制反转，也是一种设计模式。按照控制反转模式来编程，模块定义的步骤会变得繁杂，但是模块调用还是简便的；模块与模块之间的依赖性减弱，如果后期某个模块有所改动，对于其他模块的影响并不大。
依赖隔离
在项目开发中，经常会引入一些第三方类库，毕竟没有足够的时间去开发维护所有功能。引入了第三方类库，我们的代码就会依赖这些类库，就是说，如果缺失了某个类库，或者某个类库发生了一些特殊更改，那么我们的代码就不能够正常运行了。
首先，我们在引入第三方类库时，尽量选择持续更新，版本稳定的优质类库，这样的类库很少会出现停止更新，或者版本大改的情况，在使用过程会相对的稳定。
引入第三方类库之后，我们就要明白一个事实，第三方类库不可能百分百的适配我们的项目，总是会有一些已知或未知的变数，这时候，其实也是引入了风险。
对于足够优秀的类库，我们可以给予足够的信任，但是，谁又能够保证呢？还有，其他的不怎么优秀的类库呢？
我的建议是对于一些有顾虑的第三方类库，引入后不应该直接使用，而是加一层封装，其实就是加一层隔离。把第三方类库封装在一个模块里面，然后这个模块给其他模块使用，如果那个第三方类库发生比较大的变更，那么只是对应的那个封装模块需要改动，其他模块并不受影响，这样我们的代码就不会处于被人牵一发而全身动的局面。
引入一个第三方类库，我们的项目代码肯定对它有所依赖，但是通过封装隔离，项目整体上对它的依赖性并不高，因为主要都集中在那个封装它的模块里了。这样子，我们项目对自身的控制权还是在自己的手中。
最后
最后说两句：通过封装隔离，来减弱对第三方类库的依赖，也许与“控制反转”的实现方式有所不同，但是与其降低耦合的目标是一致的。