2013-03-06 49 views
1

我有一個類定義了基於訪問者模式從AST(抽象語法樹)到中間表示(IR)的轉換。兩種模型都是EMF模型,所以訪問者擴展了AST模型的抽象EMF Switch類(我使用Xtext來定義AST)。訪問者有一個狀態作爲它正在構建的IR的一些私有字段(映射局部變量,正在翻譯當前過程,添加指令的塊列表等)。Java訪問者的重構選項

訪問者實現AST的所有構造方法,因此這從caseExpressionInteger到caseStatementIf,總共有21個公共'case'方法。我也有22個私有方法,除了幾個只是助手的方法外,其中大多數方法都與狀態一起工作。

我現在正處於一個地步,我發現代碼變得太長了,我想重構它以使其更易於管理(例如通過使用更小的類)。我的問題是我有什麼選擇?

以下是我認爲的:

  • 有幾個班擴展彼此,每個班增加爲遊客
  • 有幾個獨立的類的一些方法的實現,和「主」類,代表這些類,將它們在一個單獨的類
  • 狀態混合兩種方法(有的委託,繼承一些)

你看到另一種方式?你認爲什麼最好(更容易實施/維護)?我認爲這是一個很多人必須面對的問題,因爲「訪問者」是一種非常普遍的模式。

+0

如果沒有更多信息,很難分辨出來。你可以擴大一點嗎?假設訪問者是類變得太久了,你能展示它實現的一組方法嗎?哪些是公開的,哪些是私人的?也許有關於你正在映射的模型和映射本身的更多信息? – 2013-03-06 11:32:59

+0

對不起,我編輯了原始問題以添加更多關於模型和訪問者本身的信息,這應該有所幫助:) – 2013-03-06 14:19:12

回答

2

從你的描述看來,Visitor類很有凝聚力(這很好:))。我可能會建議的唯一方法是將翻譯邏輯移動到IR Builder,併成爲將命令發送給構建者(即Director角色)的訪問者。在這種情況下,建設者將擁有內部狀態,從而利用來訪者的負擔。

也許我錯過了一些東西,但我沒有看到子類如何適合在這裏實現你的目的,所以我絕對去代表團。

HTH

+0

謝謝,這似乎是最好的解決方案,這樣我可以選擇如何分配訪問者和構建者之間的複雜性。 – 2013-03-06 15:51:08

1

一些私人字段(訪問者修改/用於執行其工作的狀態)。

聽起來像另一類,一些工作將被委派給其他類。

一般來說,您可能最好尋找委派機會。

這不是特別針對Visitor模式的存在,我們真的不能在沒有問題中提供更多細節的情況下給出非常完整的答案。

+0

感謝您的回答。對不起,我不知道我需要提供什麼級別的細節,我編輯了原始問題。 – 2013-03-06 14:16:35