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