1、Eclipse 法則(Eclipse Rule)

?

擴展者( Extender) ――添加插件

?????? 貢獻法則（ Contribution Rule ）：一切皆是貢獻。

?????? 遵循法則（ Conformance Rule ）：插件必須遵循預期的接口。

?????? 共享法則（ Sharing Rule ）：增加，不要取代。

?????? 有樣學樣法則（ Monkey See/Monkey Do Rule ）：遇到問題時，首先復制類似插件的結構。

?????? 相關性法則（ Relevance Rule ）：只有在操作有可能成功時菜顯示你所貢獻的操作。

?????? 整合法則（ Integration Rule ）：要整合，不要分裂。

?????? 責任法則（ Responsibility Rule ）：明確指出你所開發的插件時問題的源頭。

?????? 針對 API 契約編程法則（ Program to API Contract Rule ）：首先檢查 Eclipse API 契約，然后針對契約編程。

?????? Other 法則（ Other Rule ）：讓用戶可以選擇所有東西，但把那些通常不用于當前視角的選項放在 Other… 對話框中。

?????? IResource 適配法則（ Adapt to IResource Rule ）：應該盡量為領域對象定義 IResource 適配器。

?????? 分層法則（ Strata Rule ）：將語言無關的功能與特定于具體語言的功能分開，將核心性能與 UI 分開。

?????? 用戶連貫性法則（ User Continuity Rule ）：在多次會話之間，應該保持 UI 狀態一致。

?

促成者( Enabler? ) ――發布擴展點

?????? 邀請法則（ Invitation Rule ）：盡可能的邀請別人為你的作品作出貢獻，發布擴展點。

?????? 懶加載法則（ Lazy Loading Rule ）：只有在真正需要的時候才加載插件。

?????? 安全平臺法則（ Safe Platform Rule ）：作為擴展點的提供者，你必須保護好自己，不要讓擴展者的誤操作給你造成損失。

?????? 公平競爭法則（ Fair Play Rule ）：所有使用者遵守同樣的游戲規則，包括我自己。

?????? 明確擴展法則（ Explicit Extension Rule ）：明確說明平臺的什么地方可供擴展。

?????? 發散性法則（ Diversity Rule ）：一個擴展點接納多個擴展。

?????? 良好防御法則（ Good Fences Rule ）：如果要交出程序的控制權，首先保護好你自己。

?????? 用戶決定法則（ User Arbitration Rule ）：如果有多個選擇，由用戶決定使用哪一個。

?????? 明確 API 法則（ Explicit API Rule ）：將 API 與插件內部使用的類分開。

?????? 穩定性法則（ Stability Rule ）：如果你已經開始邀請其它人作出貢獻，就不要再改變游戲規則。

?????? 保守 API 法則（ Defensive API Rule ）：只暴露你有信心的 API ，但同時也應該做好準備暴露更多的 API ，因為使用者會要求你這樣做。（不含 internal 的包被認為是公開的、允許后續的擴展者使用的；不含 internal 的包，則不是打算拿到插件外使用的。）

?

發布者( Publisher) ――發布插件

?????? 許可法則（ License Rule ）：每項貢獻品都應該提供許可證。

2、Eclipse 插件(Plug-in)

何時需要一個插件類

?

?????? 每個插件都由一個插件類來代表。插件類是一個Singleton，其中提供了一些鉤子方法，可以對插件的什么周期事件作出響應。可以在插件第一次加載時讀入所需的資源，也可以在插件停止時做必要的清理工資。另外，插件還負責提高一些共享信息。

?

投影（Shadow）的世界

?

?????? Eclipse平臺啟動時會將所有插件清單文件讀入一個插件注冊表中，為每個插件創建一個投影。此時不會加載插件本身，只加載它們的描述信息。（Platform.getPluginRegistry()）

?

開發插件時，不要在項目屬性中修改構建classpath，始終在清單文件中修改。

?

在Eclipse中，每個插件都有自己的類加載器（class loader）和自己的類查找路徑（classpath），后者將繼承該插件所導入的其它插件的classpath。當插件的類加載器加載插件的第一個類時，就會激活該插件。

?

插件類加載器

?

1、? 插件類加載器的上級加載器，Eclipse的引導加載器，boot.jar

2、? 插件本身的類加載器，plugin.xml清單文件中的<run-time>元素中描述的類。

3、? 相依插件的類加載器，如果插件依賴于其它插件，在類查找時，會在內部使用一個URL類加載器。

4、? 不包括應用程序類/系統CLASSPATH變量的加載器。

?

加載擴展的全過程

?

1、? 從Eclipse平臺取得擴展點。

2、? 取得以在此擴展點上注冊的擴展（實現IExtension接口）。

3、? 對于每個擴展，取出其中以XML方式聲明的配置元素（實現IConfigurationElement接口）。

4、? 對于每個配置元素，根據該元素XML聲明中class屬性的值創建一個對象，確保定義的屬性完整、有效。

5、? 將新創建的擴展對象保存到一個集合中，而不是直接返回一個擴展對象。

?

理想的開發策略：

1、? 信心：在增加新性能或修改舊結構時，不比擔心對原代碼造成破壞。

2、? 學習：快速而自信地學習Eclipse地新領域。

3、? 設計：鼓勵自己和同事認真考慮設計，尤其是代碼地外在接口，然后去考慮如何實現。

?

測試驅動開發（Test-Driven Development, TDD）的開發循環：

1、? 編寫欲添加功能的測試。

2、? 針對這個測試引用到、暫未存在的類和方法，創建一段空的占用程序，使測試通過編譯。

3、? 實現測試，測試測試應該失敗。

4、? 盡量對實現代碼加以清掃，例如去除其中的重復代碼。

?

插件的測試策略

?

?????? 從審美的角度，每個插件應該盡可能少的依賴其它插件；從實用的角度，以測試驅動的方式開發插件的每個部分。應該首先創建測試插件，讓它依賴于新插件，以便完全用測試來驅動新插件的開發。

?

工作副本（working copy）是Eclipse JDT引入的一個概念，是原有的編譯單元在內存中的復制品。讓用戶修改時，操作的實際是Java編輯器所創建的工作副本；當用戶保存編譯單元時，Java編輯器才把副本提交到文件系統，此時對編譯單元的修改才會以Java元素變化增量的形式廣播出去。（JavaUI.getWorkingCopyManager()）

?

視角，定義了（一組）視圖和編輯器的排列方式，工作臺頁面的布局，解決某個完整問題的環境。

?

降低插件的維護成本：良好的異常處理和錯誤報告機制；提供聯機幫助文檔（Eclipse的help擴展點的擴展）。

?

分段（fragment）使開發者能夠向現有的插件中添加代碼和資源。（fragment.xml）

分段的用途：

1、? 為插件提供額外的字符串翻譯（語言包）。

2、? 為現有組件提供特定于平臺的內容。