软件工程本质的三句话总结：

第一句：软件工程的终极目标是复用。
第二句：复用永远要面对的问题是变化。
第三句：依赖是导致变化难以控制的主要原因。


关于第一句话，不想多做解释，当然，软件工程中还有成本控制、开发周期控制、文档管理等等，这些工作最终都要通过复用来解决。


关于第二句话，学过哲学的都知道绝对运动和相对静止，所以变化是绝对的、是永恒的、是无法避免的、是不可预测的。对于变化，只能想办法控制它，利用它，不要让它造成破坏，但是不要想着能消灭它。


关于第三句，造成变化的原因很多，但是依赖导致的变化是最难以控制的，也是最具破坏性的。这里举个简单的例子来说明：

某个项目的某个源文件中有如下一行代码：

String PATH="D:\AppServ\www\test";

这行代码中，我们用一个字符串把 Test 项目的路径写死在源代码中，以后我们只要用到项目路径，就引用这个字符串。这样，所有引用到这个字符串的地方都对它发生了依赖关系。这里：用一个字符串是为了简化说明问题，实际中，他有可能是个类，有可能是数据库连接配置，有可能是模块等等。

这时候，变化来了，项目被上传到 Linux 服务器上，Windows 的路径格式无法识别了；数据库也从SqlServer 变成了 MySQL，怎么办？因为一切都写死了，唯一的办法就是打开源文件，一处一处查找，一处一处修改。

于是，一些厂家提供了功能强大的应用程序服务器，大家都按照统一约定的协议，像JNDI之类的东西，把所有有可能变化的因素都配置到服务器里，哪怕他是一个简单的数据库连接字符串，或者是一个复杂的对象实例。等需要使用的时候再通过协议中约定好的接口来访问。如果发生了变化，只需要修改配置，而不需要更改源代码，这样就最大限度的削弱了依赖，控制了变化。

这种重型的解决方案对于大型的、稳定的企业级应用是安全可靠的，但是应用服务器配置的修改维护很麻烦，权限也是个问题，如果你是一个虚拟主机上的个人站长，由于需求变动比较频繁，三天两头要更改J2EE容器配置，估计你的主机服务商不会给你这个权限吧。用核武器对付游击队，似乎太过火了。

大牛们对这种情况看不过眼，于是Spring等轻量级解决方案出现了，所有配置都写道XML文件里面，给了你最大的灵活性和权限。当然，依赖并没有消除，但是反过来了，原来我想要什么需要自己去找，如果发生了变化，可能就找不到，或者找回来错误的结果；现在我想要什么，工厂会自动给我送过来，发生什么变化我不管。当然，工厂是按照配置文件的描述来生产产品的，发生变化只需要修改配置文件，最大限度的减少了破坏性和侵入性。而且，权限都在你自己手里，配置起来很方便。