組件的粒度
組件的粒度是和系統的架構息息相關的。組件的粒度確定了，系統的架構也就確定了。在小規模的軟件中，可能組件的粒度很小，僅相當于普通的對象，但是對于大規模的系統來說，一個組件可能包括幾十，甚至上百個對象。因此，對使用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。他們的定位就是提供一個對組件管理的統一模式，而組件可以單獨的使用，也可以放在另一個容器中，容器僅僅只是為組件提供了一些額外的功能，和組件本身沒有直接的依賴。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
