CDI的主旨是降低耦合度。我们已经见过了他的三种手段：

• alternatives实现了部署时的多态
• producer方法实现了运行时的多态
• contextual生命周期管理分开了bean的生命周期。

这些技术让client和server之间联系的不是那么紧密，client对于接口的具体实现不是那么care了，也不用自己去管具体实现的生老病死了。这样stateful对象彼此之间动起手来更service了。

这种松散的关系让系统更灵活，以更良好的方式应对变化。以前能提供这种灵活性的框架们，都是靠牺牲类型安全（XML描述）来玩儿活的。CDI是第一个既保证了类型安全，又提供了灵活性的技术。可以负责任的告诉你，肯定是Java EE平台上第一个这么做的规范。

CDI还有另外三种办法来进一步降低耦合度：

• interceptor可以把技术问题从业务逻辑里分出来解决
• decoratros可以把某些更具有共性的业务问题分出来解决
• evetn提醒把event的生产者和event的关注者分开

CDI的第二个目的就是强类型。依赖信息，bean的interceptor和decorator，event的关注方，这些信息都是在java代码里体现的，可以由编译器验证。

在CDI的代码里，你看不到字符串标识。这并不是框架借助于“潜规则”把他们藏起来了，而是根本就没有字符串什么事儿。

这种方式的优势显而易见，任何IDE都可以不借助特殊的工具来进行autocompletion、验证和重构。还有一个不是那么明显的好处，就是当你考虑用annotations标识一个对象、事件或interceptor的时候，你不用给他们起名字了，你可以让你的代码语义更轻快。

CDI推荐用annotations来定义概念，比如：

• @Asynchronous,
• @Mock,
• @Secure or
• @Updated,

而不是用下面这些名字：

• asyncPaymentProcessor,
• mockPaymentProcessor,
• SecurityInterceptor or
• DocumentUpdatedEvent.

annotations可以重复使用。他们可以用来在系统的不同部分做相同的修饰，可以帮助我们对代码进行分类，提高可读性。帮我们用相同的方式描述相同的关注点。使代码表达更清晰，更易于理解。

CDI stereotype把这种想法进一步发扬光大了。stereotype代表了程序架构中某种通用的组合。他可以把各种各样的annotation组合到一个annotation中，能被组合的功能包括scope，interceptor绑定，qualifier等等。

接下来，该介绍CDI的高级特性了。你会发现这些特性使得代码即易于理解又方便验证。大多数时候你不用他们也一样能让程序跑起来，但如果你能巧妙的利用他们，你会发现你很有power。