作為一個桌面應用的開發者，向
RCP
致敬的理由會是
RCP
提供了豐富的界面控件，使得基于
Java
開發桌面應用也變得容易了很多，盡管仍然不能和基于
VB
、
Delphi
去相比；對于我而言，盡管使用
RCP
也是為了開發桌面應用，但
RCP
給我帶來的更多的感覺是在它充分發揮插件化系統的優勢方面，
RCP
可以視為基于
OSGi
構建插件化系統的最佳實踐的指導，從
RCP
的設計中，可以學習到如何讓應用做到模塊化、讓應用做到動態化，甚至還可以學習到象如何自動生成界面這樣的細節設計思想，盡管我自己基于
OSGi
做應用型的產品也做了一段時間了，但自己仍然一直感覺到在發揮插件化系統的優勢方面還有不小差距，
RCP
可以看做是基于
OSGi
做插件化應用系統的最佳實踐，其中的不少設計方法甚至都可以整理成為基于
OSGi
做插件化應用系統的設計模式，讓我們進入
RCP
之旅，揭開面紗，一探其本質吧，相信大家在了解了
RCP
的設計思想，看過其代碼后，不得不對
RCP
表示崇高的敬意，大師之作，不同凡響。
致敬理由一：即插即用
/
即刪即無的設計
/
實現指導
在構建插件化的應用系統的時候，我們通常希望做到以下三點：
1.????????
通過增加插件來動態擴展系統功能，包括功能的入口等，最重要的就是不要因為增加的新的插件，而導致對原插件的修改，做到即插即用，
OSGi
本身提供了基于插件動態擴展系統功能的支持，但是否可以真的做到即插即用，是否可以不導致對原插件的修改，這個還是要看設計者的功力；
2.????????
通過刪除插件來動態移除系統功能，包括功能的入口等，最重要的就是要讓插件的卸載不影響到系統的運行，這個和
1
里面所說的情況也是一樣的，
OSGi
是可以支持這樣的要求，但應用系統是否能做到還是看設計者的功力；
3.????????
通過增加或更新插件來動態改變系統行為。
RCP
呢，通過基于
OSGi
來保證其插件化以及動態化可實現的情況下，還定義了擴展點的機制，而正是因為擴展點的機制，使得
RCP
在設計角度能夠更好的達到了我們構建插件化應用系統的前兩個目標，同時
RCP
通過其對桌面應用支撐的設計為我們展示了擴展點的最佳實踐方法，將界面按照對象的思想進行劃分，在劃分的過程中根據職責形成插件，暴露出擴展點，最后形成了象樹一樣的結構體系，如圖所示：
圖表
1
RCP
結構示意圖
這種設計方法最佳的一個地方就在于充分的做到了真正的即插即用、即刪即無的情況，典型的例子就是在
RCP
中可以通過擴展實現
Perspective
，將這個插件安裝上后就可以在
RCP
中看到這個
Perspective
，刪除這個插件后
RCP
中自然就看不到這個
Perspective
了。
從
RCP
的結構體系上，可以看出
RCP
在基于擴展點的設計思想上是怎么去設計的，它的設計思路采取的就是從頂至下、按照職責進行劃分、形成插件的方法，插件中需要支持動態擴展的部分則做成擴展點，從而形成一個非常容易擴展的開發平臺。
這對于
B/S
系統的設計有什么指導的地方呢？至少在我自己目前的基于
OSGi
的產品的
B/S
部分上，我承認并沒有做到真正的即插即用、即刪即無，在安裝一個插件后其菜單的鏈接需要手工的加上、在刪除一個插件后其菜單的鏈接也需要手工的刪除，而模塊內的按鈕呀等等元素，也是同樣如此，并沒有做到說增加一個插件，模塊內的按鈕就可以自動增加這樣的情況，而這呢，其實一定程度上就削弱了插件化帶來的好處，
:)
，當然，這里的例子說的有些極端了，并不是每個按鈕、每個界面都要追求完全的插件化的，但這種設計思想是非常有用的，系統中需要支持插件化的地方多著呢，在這樣的場景下
RCP
就提供了實現的設計思想和參考了，而且這種設計思想還可以延伸到后臺模塊部分，來看看參考
RCP
使用擴展點的方式來改造下
B/S
系統的設計方法。
先來看看界面部分，界面怎么樣去設計，使其能夠支撐插件的即插即用、即刪即無這也是非常關鍵的，這個部分幾乎是完全可以參考
RCP
的設計，但要考慮
B/S
系統的特殊性，例如
B/S
系統在界面展現上采用
Html
這樣的方式顯然更為適合，在這樣的設計的情況下，
B/S
系統界面中的公用菜單、按鈕等部分就可以由各模塊的插件擴展來構成了，而當插件卸載時，這些公用菜單、按鈕中的東西自然就沒有了，而對于模塊內的元素也需要考慮采取類似的設計，把握住設計原則就行了，需要支持動態擴展的部分就做成擴展點，
Eclipse
對于這種擴展稱為貢獻，這個名詞取的實在是太好了。
再來看看后臺模塊部分，后臺模塊部分之前一直說的在
OSGi
中采用
Hibernate
比較的麻煩，只能采用將所有模塊的
po
都放入同一個
Bundle
的折衷方案，而其實采用類似擴展點的設計方法的話，就可以實現各
PO
放入各模塊自己的
Bundle
中了，這個我會通過
demo
的方式來進行說明，其實這樣的方法同樣可以衍生到
webwork
那些中去，讓這些傳統的開源的東西都能夠支撐插件化。
從這個方面來看，
RCP
的擴展點的設計思想為實現即插即用、即刪即無提供了可行的設計方式，同時它的實現方法更是為我們如何采用擴展點機制來實現這個提供了指導，在這里呢，也要糾正了下自己以前對于
RCP
的擴展點的看法，盡管擴展點的實現確實可以基于
OSGi
的
service
的方式來實現，但在很多場景下確實不如
RCP
本身的擴展點機制好用，例如在幫助視圖中，就是一個典型的場景，因為那只是替換了一個幫助的文本信息和圖片而已，根本用不著去寫類來實現，這點上來說擴展點的機制還是非常好用的，
Equinox
中現在也有擴展點這個插件，還是比較爽的，
J
。
即插即用、即刪即無的支持使得系統可以很好的以插件的方式來進行組裝，做系統的時候就象在種樹，先把系統的根撒下，讓根長出主干，在主干上培育出枝葉，枝葉上結點果實，整顆樹就這么養成了，當不需要了某個果實的時候，把它摘下來吃了，當不需要了某顆枝葉的時候，把那顆枝葉砍了，而這都不會影響到主干，當希望樹上形成別的果實的時候，甚至都可以接上個不同的枝葉，讓它長出不一樣的果實，比普通樹強多了，改名成高科技樹算了，
J
。
?
致敬理由二：動態的選擇插件來形成功能
/
界面
擴展插件是一個需要支持的方面，但怎么樣根據時機來選擇合適的插件呢，這個問題顯然就是在支持擴展插件后的一個更重要的問題了，為什么這么說呢，一個典型的場景如下：
系統中幾個插件都擴展提供了右鍵彈出的菜單，在運行的過程中，肯定是希望插件只彈出自己的那部分擴展的菜單，而不會希望什么菜單都出現，這呢，就需要動態的去選擇插件來形成菜單，在
RCP
中這塊的設計采用的是在擴展點中增加標識的方式，這樣的話在獲取擴展點實現的時候就可以通過獲取相應的標識來進行過濾，這個功能呢，和
OSGi
中支持
service
的過濾是一樣的，雖然這不屬于
RCP
的創意，但這也是一個實踐的不錯的指導。
在形成界面方面
RCP
采用了同樣的方法，例如在一個屬性窗口中，系統可以自動的根據其中字段擴展點的實現加上標識的過濾來組裝出不同的界面，把這個設計思想引入到
B/S
界面的自動生成上是不是也是個不錯的思想呢，
J
。
?
目前對
RCP
了解還不是非常的多，設計角度而言最讓我心動的就是上面的兩個理由，但其實
RCP
還提供了非常多的細節的可參考的東西，那都是非常值得學習的，
RCP
的代碼非常的值得一讀，相信大家在讀了后都會覺得不亞于一頓大餐美食，希望大家多多挖掘，共同分享這頓難得的美食。