爲了我的目的,創建一個HypotheticalType
和一個HypotheticalMethod
完成了工作。我附上了一個概述,以防其他人需要遵循此路徑。
首先我創建了一個HypotheticalType
並使其實現了IType
接口。我在修改過的嚮導中的適當位置實例化了其中的一個。使用Eclipse的大綱視圖,我在我的新類的所有方法上創建了一個方法斷點。這讓我可以在執行嚮導期間檢測到實際調用的方法。我還修改了構造函數,以作爲String
,我需要該向導處理的類的名稱。
在本練習中,幾乎所有新方法都被忽略。我發現我可以保持默認的實現爲所有方法(返回null或返回在大多數情況下假),除了以下幾點:
- 構造
exists()
- 沒有修改需要
getAncestor(int)
- 沒有修改需要,但是可能會返回我的假設類的包,例如如果我的班級是java.lang.Object.class
,請返回java.lang
。
getDeclaringType()
- 無需修改
getElementName()
- 修改爲返回類名稱,例如:如果我的班級是java.lang.Object.class
,請返回Object
。
getElementType()
- 修改返回IJavaElement.TYPE
getFlags()
- 沒有修改,但可能是
getMethod(String, String[])
- 修改返回一個新HypotheticalMethod(name)
getMethods()
- 修改返回新IMethod[] { new HypotheticalMethod("dudMethod") }
在過程中,我發現我需要能夠返回HypotheticalMethod
,所以我創建了該類型,並從IMethod
繼承,並且使用相同的技術來確定哪些方法必須實施。這些是被調用的唯一方法,而這個嚮導運行:
- 構造 - 添加
String
參數的方法
exists()
的名字帶來 - 沒有修改需要
isMainMethod()
- 沒有修改需要
這涵蓋了我原來的問題的解決方案。 Zoltán,我將按照您在即將到來的迭代中的建議進行操作,並嘗試在所需類不在此項目的類路徑中的情況下協助用戶,以及在某些項目中不需要類的情況下但在工作區中。
(有趣的是,投票答覆我自己的問題並不是像我這樣的新用戶可以做的事情。) –
目前,我正在實現實現IType的HypotheticalType對象的想法。我希望現有的嚮導代碼實際上只需要IType和相關接口的少數幾個方法,僅僅將它們視爲包含尚未導入類的名稱的榮耀化字符串。 –
當然,另一種方法是大幅改進現有的嚮導代碼以使用Strings。但是,這感覺就像是二流的解決方案。 –