先讲结论：
DI(Dependency Injection) 跟 IoC(Inversion of Control) 的原始目的都不是解耦
接着说明一下 DI 跟 IoC：
首先 IoC 的目的是控制权的转移，如原 PO 文章里面原本是在 Employee 里面 new
Address，而采用 IoC 之后这样的行为就转移到外部来决定
而之所以要转移控制权是为了好维护，例如可能 new Address 的行为将来要调整就不用
动到 Employee
而 DI 只是搭配 IoC 来将物件注入需要的物件当中，例如透过 Employee 的 Constructo
r
来注入 Address 的实例
在这两个 pattern 当中都没有要求转移控制跟注入的物件是什么，你要注入抽象或实作
都可以，也因此并不能直接帮助你解耦
而且 Spring 只是提供 DI/IoC 相关功能来帮助管控物件生命周期，并且降低自己实作的
复杂度，实际上你完全可以自己实作，例如在 main 自己写注入
如果你的目的是要解耦的话，要考虑的应该是 SOLID 里面的 DI(Dependency Inversion)
，利用抽象隔离实作
而且首先要说明的是一般软件在说得解耦都是指对实作解耦，毕竟两个元件要能协作，不
可能两边都完全不知道对方，而知道 (know) 对方就是一种耦合
SOLID 的 DI 就是利用抽象帮助你解耦 (strong coupling to weak coupling)
而在有抽象隔离的前提下，利用 DI/IoC 就能帮助你大幅降低后续修改实作的时候，元件
互相影响的可能性，并且方便测试，尤其是单元测试
接着利用 Spring 提供的 DI/IoC 功能可以更进一步减少实作的复杂度，让 DI 实作的
boiler plate 部分交给 Spring 管理达到关注点分离的效果，让你可以专注在逻辑面
以原 PO 的例子来说算是有用到 DI/IoC 的概念，但实务上以这个例子来说可能根本不需
要用到 Spring 的功能，而比较需要考虑的是 Address 跟 Employee 要如何互动
比较常见的例子是 Spring MVC 分层架构下要在 Controller 层使用 Service 或 Servic
e
层使用 Repository
尤其是 Spring Data JPA 常用的 CrudRepository 或 JpaRepository 原本就是
interface，你根本不需要知道 Spring 帮你注入的实作是哪个，加上也只需要用
@Autowire 或 Contructor 方式注入，完全不须自己实作 new 的部分，甚至注入的实作
本
身的依赖也一并由 Spring 帮你搞定，达到关注点分离，让你可以直接在 Service 使用
Repository，借此达到专注在 Service 本身的逻辑
结论：
DI(Denpendency Injection) 跟 IoC(Inversion of Control) 的目的都不是为了解耦
要解耦先考虑用抽象隔离，再考虑用 Spring DI/IoC 的功能帮助降低实作的复杂度
至于抽象稳定那就是另外的问题了...