1

ビジター パターンに基づいて、AST (抽象構文ツリー) から中間表現 (IR) への変換を定義するクラスがあります。どちらのモデルも EMF モデルであるため、ビジターは AST モデルの抽象 EMF Switch クラスを拡張します (私は Xtext を使用して AST を定義しています)。ビジターには、構築中の IR のいくつかのプライベート フィールドとしての状態があります (ローカル変数のマッピング、変換中の現在のプロシージャ、命令を追加するブロックのリストなど)。

ビジターは AST のすべての構造のメソッドを実装するため、これは caseExpressionInteger から caseStatementIf まで、合計 21 個のパブリック「ケース」メソッドになります。私は 22 個のプライベート メソッドも持っています。ヘルパーであるいくつかのメソッドを除いて、これらのほとんどは状態で動作します。

現在、コードが長くなりすぎていることがわかりました。コードをリファクタリングして、管理しやすくしたいと考えています (たとえば、クラスを小さくするなど)。私の質問は、どのようなオプションがありますか?

これが私が考えたことです：

  • 複数のクラスを相互に拡張し、各クラスでビジターのいくつかのメソッドの実装を追加します。
  • いくつかの独立したクラスと、これらのクラスに委譲する「メイン」クラスを持ち、別のクラスで状態を渡します
  • 2 つのアプローチを混在させる (一部のデリゲート、一部の継承)

別の方法が見えますか？何が一番良いと思いますか (実装/保守が簡単)? 「訪問者」が非常に一般的なパターンであることを考えると、これは多くの人が抱えていたに違いない問題だと思います。

4

2 に答える 2

2

あなたの説明から、 Visitor クラスは非常にまとまりがあるようです (これは良いことです:))。私が提案できる唯一のことは、変換ロジックを IRビルダーに移動し、ビルダーにコマンドを送信する訪問者 (つまり、ディレクターの役割) になることです。この場合、ビルダーは内部状態を持っているため、訪問者からの負担を活用できます。

何かが足りないのかもしれませんが、目的を達成するためにサブクラス化がここにどのように適合するかわかりません。

HTH

于 2013-03-06T14:52:31.577 に答える
1

いくつかのプライベート フィールド (訪問者が作業を行うために変更/使用する状態)。

一部の作業が委任される別のクラスのように聞こえます。

一般的に言えば、委任の機会を探したほうがよいでしょう。

これは、訪問者パターンの存在に特に固有のものではなく、質問にもう少し詳細がなければ、非常に完全な回答を提供することはできません。

于 2013-03-06T11:38:47.387 に答える