应用结构：pattern的终结是anti-pattern

以下讨论只针对应用开发，库开发的情况有所不同。

起初，人们大多在用C，人们讨论函数（functions）和编译单元（compilation unit）。

OO（面向对象、对象导向、物件导向）兴起后，人们开始认为，全局函数不好，全局变量不好，应该都封装到类（class）里。

随着程序越来越大，对象越来越多，人们发现，有很多对象几乎要被所有其它的类引用，而且这些对象被四处传递，不但啰嗦，而且难于修改。于是，singlton pattern（单实例模式）火了。从C的角度说，singleton不过是包装了一下的全局变量，不过既然包装了，那也就OO了，不evil了。很多人都会很自豪的讲解这个模式。

不久，有人提出了质疑。Singleton的本质是保证只能有一个实例，而不是全局访问，所以很多人对这个pattern的用法是错的。而且很多时候，我们其实是需要替换一个Singleton的实现的,尤其是测试的时候。甚至有人认为，Singleton其实是anti-pattern。于是出现了各种Singleton和Factory Pattern（工厂模式）的结合体，Singleton的服务被抽象成接口，可以通过代码或XML等配置具体用哪个类的实例。于是，Service Locator Pattern诞生了，我们不再需要为一个一个类各自实现这套似singleton又非singleton的逻辑，一切都交给ServiceLocator统一解决。各模块都从ServiceLocator请求自己需要访问的模块接口。

不久，人们又质疑了，ServiceLocator无非是另一种形式的Singleton而已。甚至更糟糕，它隐藏了模块之间的以来关系，象一个service没有register这种问题，只有运行时才能发现报错。而且，所有的模块都要依赖于ServiceLocator，这是一个不好的耦合。尤其是，全局唯一的ServiceLocator不利于并行和Test时的Mocking。

之后，IoC（Inverse of Control，控制反转)或者说Dependency Injection（依赖注入）火了，而Service Locator被打倒作为Anti-pattern(反面模式，坏榜样)。IoC的核心思想就是，应用定义各模块的标准接口，一个模块如果要引用其它模块，那么以构造参数或者属性的形式接收其它模块接口的实例，而它自己并不管如何取得这些实例的引用。之后由应用程序的顶级逻辑负责组合这些模块。现在已经有很多IoC Framework来简化组合这些模块的逻辑。

我们今天所在的位置，就是IoC这一步。如果你还没有走到这一步，你已经out了。

Bonus话题：IoC和什么有点象呢？古老的C程序，.h文件定义接口，.c文件引用它所需要的头文件，编译器会把它们组合起来……