在以前的公司寫的，現在離職了，感覺放在公司論壇有點浪費，現在看思想還挺新穎的。:)
養成"面向組件編程"習慣
首選讓我們看看什麼是面向組件編程:
面向組件編程
面向組件編程的縮寫是COP。COP是對OOP的補充，幫助實現更加優秀的軟件結構。組件的粒度可大可小，需要取決於具體的應用。
在COP中有幾個重要的概念：服務,服務（Service）是一組接口，供客戶端程序使用。例如，驗證和授權服務，任務調度服務。服務是系統中各個部件相互調用的接口；組件，組件（Component）實現了一組服務，此外，組件必須符合容器訂立的規範，例如，初始化，配置、銷燬。
COP 是對一種組織代碼的思路，尤其是服務和組件兩個概念。在下文會提到Spring框架中，就採用了COP的思路，將系統看作一個個的組件，通過定義組件之間的協作關係（通過服務）來完成系統的構建。這樣做的好處是能夠隔離變化，合理的劃分系統。而框架的意義就在於定義一個組織組件的方式。
理解組件
組件不是一個新的概念，Java中的javaBean規範和EJB規範都是典型的組件。組件的特點在於他定義了一種通用的處理方式。例如，JavaBean 擁有內視的特性，這樣就可以通過工具來實現JavaBean的可視化。而EJB規範定義了企業服務中的一些特性，使得EJB容器能夠爲符合EJB規範的代碼增添企業計算所需要的能力，例如事務、持久化、池等。
所以，組件比起對象來的進步就在於通用的規範的引入。通用規範往往能夠爲組件添加新的能力（就像上面所討論的），但也給組件添加了限制，例如你需要實現EJB的一些接口。以下我們將討論組件的一些相關問題：
組件的粒度
組件的粒度是和系統的架構息息相關的。組件的粒度確定了，系統的架構也就確定了。在小規模的軟件中，可能組件的粒度很小，僅相當於普通的對象，但是對於大規模的系統來說，一個組件可能包括幾十，甚至上百個對象。因此，對使用COP技術的系統來說，需要正確的定義組件的粒度。較好的定義粒度的方法是對核心流程進行分析。
--------------------------------------------------------------------------------------------------------------------------------------
我對面向組件編程的看法:
要提高代碼的重用性和生命力,其中一個比較好的方案是把公用部分提取出來做成一個組件包.
比如一個開源的包,jxl.jar,javamail.jar,等等都是以不同粗細粒度的方式把用於特定方面的代碼
進行了優化和設計組合而成的接口.他們定義了一組可擴展性的api,這些api不會侷限於某個特定的
業務,比如我們說的某個項目,某個需求.
這些包通過對代碼的不斷改進來提升組件的功能和涉及面,從而版本越高,組件包越穩定.例如我們所瞭解
的struts.jar.可以認爲它是一個控制層的組件包.
面向組件編程應該也是敏捷過程所要求的,通過良好設計的組件包,我們在開發的時候有幾點優勢.
1.組件包有實現時,在需求緊張的情況下我們不需要花過多的時間去考慮另一種方案.直接利用
組件包理的穩定的代碼何樂而不爲?
2.我們可以專注於業務的實現,而不需要考慮於業務無關的編碼.
3.採用了穩定的組件包,增強了應用的穩定性和健壯性.
4.我們可以節約時間來學習更先進的技術.原始的技術因爲已經得到了累計(通過組件包的方式).
5.採用組件編程,代碼更少,但是功能更強,更穩定.
例如我提出的工具包組件:報表工具組件:就是採用了面向組件編程的方式,但是面向組件編程對代碼的要求很高,需要大家一起來探討和
共享(是不是也體現了敏捷過程中的要點?呵呵).