组件的粒度
组件的粒度是和系统的架构息息相关的。组件的粒度确定了，系统的架构也就确定了。在小规模的软件中，可能组件的粒度很小，仅相当于普通的对象，但是对于大规模的系统来说，一个组件可能包括几十，甚至上百个对象。因此，对使用COP技术的系统来说，需要正确的定义组件的粒度。较好的定义粒度的方法是对核心流程进行分析。
针对接口
接口和实现分离是COP的基础，没有接口和实现的分离，就没有COP。接口的高度抽象特性使得各个组件能够被独立的抽取出来，而不影响到系统的其它部分。
接口和实现分离有以下几个好处：
1、 在模块/组件/对象之间解耦。
2、 轻松的抽换实现，而不用修改客户端。
3、 用户只需要了解接口，而不需要了解实现细节。
4、 增加了重用的可能性。
IOC
IOC是Inversion of Control的简称。它的原理是基于OO设计原则的好莱坞原则(The Hollywood Principle)：不要访问我，我们将访问你。也就是说，所有的组件都是被动的(Passive)，所有的组件初始化和调用都由容器负责。
在Brian Foote的论文(http://www.laputan.org/drc/drc.html)中解释了IOC的概念。
qca网站上对IOC的讨论(http://qca.cn/common/IOC.htm)
IOC有几种实现的类型，包括基于方法参数调用的Method-based (M) IoC，它把组件传递给每个方法调用;基于接口的Interface-based (I) IoC(通常称为类型1)，它使用接口来声明组件之间的依赖性，例如，Serviceable, Configurable;基于Setter方法的Setter-based (S) IoC(通常称为类型2)，它使用setter方法来设置组件之间的依赖性;基于构造函数的Constructor-based (C) IoC(通常称为类型3)。
在Martin Fowler刚刚完成(2004-1-24)的Inversion of Control Containers and the Dependency Injection pattern一文(http://www.martinfowler.com/articles/injection.html)中，将IOC模式称为Dependency Injection模式。
IOC是框架开发的一个基本原理。在开源软件中，不少的容器类框架都采用了IOC的思路。例如PicoContainer(http://www.picocontainer.org/)和Spring(http://www.springframework.org/)
组件污染
在IOC的第一类型中，由于组件需要实现一些特定的接口，或是从某个类集成。这将使得组件受到一些约束(称为Invasive)，例如组件移植不便。另一种情况是组件需要依赖于一个特定的容器，最为典型的就是EJB，组件无法脱离容器单独存在，这也使得组件受到约束。这两种情况都属于组件污染。
最理想的组件是只专注于自身工作的组件，它没有其它额外的逻辑。不过按照这种标准，目前大部分的代码都是不符合的。因此，目前在开源软件界出现了一些轻量级的容器框架，典型的如上文提到的PicoContainer和spring。他们的定位就是提供一个对组件管理的统一模式，而组件可以单独的使用，也可以放在另一个容器中，容器仅仅只是为组件提供了一些额外的功能，和组件本身没有直接的依赖。
文章来源于领测软件测试网 https://www.ltesting.net/
