擴展Eclipse的Java開發工具(一)

2019-11-18 13:02:57

字體：大中小

來源：轉載

供稿：網友

　　Eclipse 的 java 開發環境的重構（refactor）能力是它提供的最有用的特性之一。本文將向您介紹創建您自己的重構（作為 Eclipse 的自然擴展）步驟。本文所提供的解決方案的許多部分摘自最近出版的 The Java Developer's Guide to Eclipse 一書。
　　
　　由于 Eclipse 具有功能強大的 Java 開發環境，這使它獲得了人們的一致好評。這個 Java 開發環境（再加上團隊環境和其它基礎功能）使 Eclipse 成為引人注目的集成開發環境，對 Java 開發人員來說，這是個好消息。而且，Eclipse 還是一個開放源碼項目。但真正使人們對 Eclipse 感到興奮的是它提供了擴展的可能性。
　　
　　許多基于 Eclipse 的商用產品都顯示出這種提供集成產品的方法的實際意義。例如，IBM WebSphere application Developer 和 Rational XDE 就說明了 Eclipse 已具有的影響。這些產品和其它基于 Eclipse 的產品降低了用戶的“學習曲線”，因為它們具有類似的用戶界面。當然，對于大型軟件公司來說，這頗有價值，但是對于小公司或個人有什么用嗎？
　　
　　這正是 Eclipse 擴展性能力讓人感愛好的地方。不僅那些擁有大型開發組織的公司可以用它進行集成，任何愿意花些時間學習幾個 Eclipse 框架的人也都可以利用這一能力?！芭恫?，”您可能在想，“別再提什么框架；我沒時間學習更多框架?！辈槐負模贿@學起來很快而且相當輕易。在您的另一絲疑慮在頭腦中開始形成之前，先聲明一點，本文絕不是對 Eclipse 進行毫無價值的“hello world”式擴展。請放心，在如何增強 Eclipse 的 Java 開發環境的生產性使用方面，您將看到實際的價值以及一個清楚演示。您甚至還可能有點驚異地發現：要完成某些相當令人驚異的事情，只要幾十行代碼就可以了。
　　
　　本文將向您展示什么是可能的，從哪里開始，并將向您提供開始時需要什么的可靠評價。盡管擴展 Eclipse 是一個高級主題，但是您只要先了解如何使用 Eclipse 的 Java 開發環境就可以了。
　　
　　自己輕松重構成員可視性
　　最初在編寫代碼時，我沒有過多地擔心將方法可視性歸為 default（包）、PRivate、public 還是 protected。在創建方法時，我使它們都為 public。只有當我最后定下了包的組織結構并完成了對方法的重構－不管是通過從現有代碼抽取出新方法、在層次結構中上移或下移方法還是將方法整個地移至其它類中－我才會重新檢查方法的可視性。我認為，在我知道最終類的模樣并實際使用過代碼之前，我不想聲明我的“客戶們”可能需要什么。換句話說，在共享新框架之前，必須確定什么是實現細節，什么是必需的，這樣別人才能夠擴展它。
　　
　　假如只需在 Outline 視圖、Hierarchy 視圖或任何您查看方法的地方選擇方法－然后通過單擊菜單選項，就可以將一個或多個方法設置成所期望的可視性－那么這會非常方便。誠然，我習慣了在我使用 VisualAge for Smalltalk 那段日子里學到的這一功能。圖 1 顯示了對 Eclipse 的 Java 開發環境中 Java 編輯器的 Outline 視圖上下文的擴展。
　　　擴展Eclipse的Java開發工具(一)（圖一）

　　圖 1. 對方法的上下文菜單進行的擴展
　　從用戶的角度而言，這很巧妙，因為這是引入用戶界面的很自然的方法。沒有任何暗示說這些新的菜單選項不屬于 Eclipse 最初的 Java 開發工具（Java Development Tool，JDT）。事實上，那就是菜單級聯使用“soln”前綴的原因－這樣您就可以分辨出它是一個擴展！而且，開發人員不必記住只有在特定視圖或編輯器中才可以使用這些選項，因為只要方法顯示在哪里，它們就可以在哪里顯示。
　　
　　簡述“Hello World”
　　“嘿，等一下，您承諾過不會有‘Hello, World’的！”是的，但在我們開始討論真正有趣的事情之前，確實需要先來了解一下 Eclipse 的基礎。所以，假如您從未編寫過自己的 Eclipse 擴展，那么請和我一起快速了解一下 Eclipse 的體系結構和插件開發環境。否則，請跳至下一節。繼續這次“旅行”！
　　
　　本質上，Eclipse 是一組松散綁定但互相連接的代碼塊。假如搞清楚這些代碼塊如何被“發現”，以及它們之間怎樣相互發現和擴展，就能了解 Eclipse 體系結構的基本原理。
　　　擴展Eclipse的Java開發工具(一)（圖二）

　　圖 2. Eclipse 平臺體系結構
　　這些功能單元稱為插件。Eclipse 平臺運行時（參見圖 2）負責在名為 plugin.xml 的文件中查找這些插件的聲明（稱為插件清單），每個 plugin.xml 文件都在各插件的子目錄中，這些子目錄位于 Eclipse 的安裝目錄下名為 plugins 的公共目錄（具體而言，就是 /eclipse/plugins）。根據這些文件，Eclipse 平臺運行時就在啟動時在內存中構建一個全局注冊表，稱為插件注冊表，根據這個注冊表，給定的插件就可以在運行時確定其它哪些插件希望擴展它。希望被其它插件擴展的插件將聲明一個擴展點。這是插件的某種“電源板”，通過對插件聲明擴展，其它插件就可以利用這個插件。
　　
　　回到我們的示例，那么任務就是通過查找滿足我們需要的相應擴展點來決定從哪里“插入” Eclipse。幸運的是，一旦使用 Eclipse 一段時間后，您就會知道有數量驚人的東西可以使用，盡管可能您還沒有實際使用過。這是因為您在 Eclipse 用戶界面所看到的與由構成 Eclipse 插件的類所建的模型通常幾乎是一一對應的。圖 3 使這一點更為清楚：
　　擴展Eclipse的Java開發工具(一)（圖三）

　　圖 3. 視圖及其模型
　　這里我們看到一系列普通的用戶界面，右側的是最廣為人知的用戶界面－命令提示符（Command Prompt）窗口，在其中用 dir 命令顯示文件系統內容，然后是左邊專門化程度較高的視圖－ JDT 的 Package EXPlorer。從用戶界面的角度來看，所有這些視圖都將同一“模型”（也就是一些文件）的表示可視化。作為 Eclipse 用戶，我們很自然地會希望這兩個 Eclipse 視圖同時向我們提供查看同一事物的不同方法：Navigator 展示了部分操作系統文件的專門化視圖（Eclipse 的工作空間），而 Package Explorer 向我們展示了同樣的一些文件，這些文件是用對 Java 程序員而言更自然更高效的方法組織和表示的。
　　
　　通過了解 Eclipse 用戶界面如何反映其底層模型，以及 Eclipse 模型如何成為相互構建的基礎，這向我們提供了該如何找到“插入”我們擴展的最佳位置的重要線索。顯示在視圖下面的 Eclipse 接口名稱 IFile 和 ICompilationUnit 就是我們可以預期從構成 Eclipse 的模型中獲得的兩個接口示例。由于它們通常對應于用戶界面中顯示的控件項，所以您已經對通過編程獲得的效果有一個直觀的感受。
　　
　　這是我們“旅行”的第 I 部分。在第 II 部分中，我們將討論開發解決方案。我們不打算提供這個解決方案并逐一解釋，探索其中的一些奧秘，這不是更有趣嗎？讓我們首先討論與以下這個問題相關的一些問題：使用我們自己的方法可視性重構能力來擴展 JDT。
　　
　　把問題問在點子上比知道答案更重要
　　
　　我們先探討一些常規問題：
　　
　　在用戶界面中，如何顯示擴展，以及顯示在何處？
　　
　　通常如何擴展用戶界面？
　　
　　對用戶界面的擴展如何知道類似于“選擇”這樣的基本事件？
　　
　　我們對基本 Eclipse 領域有了很好的了解之后，將轉向一些特定于 JDT 的問題：
　　
　　如何擴展 JDT 的特定元素的用戶界面（象 Outline 視圖中顯示的成員）？擴展視圖還是它們的底層模型？
　　
　　Package Explorer 中顯示的元素和其它視圖（如 Outline 視圖）中顯示的相同元素之間有什么關系？我們的擴展需要知道它們之間的任何區別嗎？
　　
　　如何通過編程更改 JDT 模型？
　　
　　怎樣分析 Java 源代碼以進行修改？

上一篇：擴展Eclipse的Java開發工具(二)

下一篇：擴展Eclipse的Java開發工具(三)