动手之前先想想

SERVICE LOCATOR OR DI

这两种方法都能够将一些类解耦，那关于这两种模式的区别主要在于这些插件怎么样被用到工程之中，如果是用service locator的话，系统会告诉locator具体他要的是什么，而用DI的话，没有明确的请求，由容器来控制反转。

IOC是大部分framework所提供的功能，不过它是有代价的，他不容易被理解，而且难以被debug，所以我建议最好不要使用除非你真正的需要他，但不是说他是一个坏的东西，我们所需要的是平衡。

他们主要的区别是locator跟service的是实现是独立的，应用对locator也是独立的，但是在应用中你得知道有这个locator，选择他们的原因主要就是看是否独立。

不过用DI会让人一下子看出这些类的依赖关系式怎么样的，而在locator中你必须从源代码的层面来找所需要的类。

CODE OR CONFIGURATION FILES

存在这样一个问题，是否确实应该使用配置文件或者编码去实现API，组成一个服务，在许多情况下，一个应用很有可能被分布在

很多地方，一个独立的配置文件很有意义，在很多情况下，这将是一个xml文件。然而在很多情况下， 用代码写死在里面会方便的多，一种情况是你是否有一个简单的程序，不需要许多的配置变量。在这种情况下，少量的代码就比xml更加清晰。

一种极端的情况是，一个应用异常复杂，包含了条件步骤，一旦你开始接触一门编程语言，你还是最好用一门语言来写出一个清晰的程序。

大部分人总是对于定义配置文件过于狂热，一门编程语言总能够直接的，很方便的加载配置，现代的编程语言总是能够将小的部分集成到系统之中，有许多脚本可以帮助我们做到这些。

我们可以看到，现在在java世界中出现了一些不和谐的配置文件，每个部分都有他的配置文件，而且与其他部分的配置文件都不一样，如果我们有一打应用，就会有一打配置文件，这是很不方便的。

最好是对于每种配置方式做一个统一的接口，把配置文件当成一个可选的特性，这样你可以用编程接口处理配置文件。这样你写出了一个组件，你可以选择把他用作编程，或者配置文件，或者客户自己写配置文件都可以接入这个系统。