2

ツリー構造とさまざまなノード タイプのビジター パターンの使用法を修正したいと考えています。ツリー構造のすべてのノードはコールバック メソッドを実装する必要があり、ビジターの実装では、各ノード タイプ (または少なくとも関心のあるタイプ) に対して次のようなものを実装する必要があります。

/**
 * Do something when visiting a {@link CommentNode}.
 * 
 * @param pNode
 *          the {@link CommentNode}
 */
EVisitResult visit(final @Nonnull CommentNode pNode);

/**
 * Do something when visiting an {@link ElementNode}.
 * 
 * @param pNode
 *          the {@link ElementNode}
 */
EVisitResult visit(final @Nonnull ElementNode pNode);

私はトランザクションカーソルセマンティクスを使用してツリー構造をナビゲートし、acceptVisitor-method を提供しています。これは、カーソル内に次のものを実装しました。

@Override
public EVisitResult acceptVisitor(final @Nonnull IVisitor pVisitor) {
  assertNotClosed();
  return mCurrentNode.acceptVisitor(pVisitor);
}

ただし、ビジターはAPIの欠陥です。たとえば、ノード自体を公開することElementNodeは非常に危険です。すべてのノードタイプに許可されている変更は、特定の書き込みトランザクション内からのみ可能でなければならないためです(提供するカーソルとして実装されています)ツリー構造をトラバースするメソッド)。そうしないと、変更が表示されず、commit().

この状況を回避する方法について何か提案はありますか? メソッドのシグネチャは確かに異なる必要があるため、ビジターインターフェイスを提供できるとはどういうわけか疑問に思っています...

わかりました、不変の「ラッパー」またはプロキシ クラスを提供します。

/** Mutable {@link CommentNode}. */
private final CommentNode mNode;

/**
 * Constructor.
 * 
 * @param pNode
 *          mutable {@link CommentNode}
 */
private ImmutableComment(final @Nonnull CommentNode pNode) {
  mNode = checkNotNull(pNode);
}

/**
 * Get an immutable comment
 * 
 * @param pNode
 *          the {@link CommentNode} which should be immutable
 * @return an immutable instance
 */
public static ImmutableComment of(final @Nonnull CommentNode pNode) {
  return new ImmutableComment(pNode);
}
4

1 に答える 1

2

カーソルクラスにプロキシでノードをラップさせることができます。これにより、ノードと同じインターフェイスが訪問者に公開されます。その場合、訪問者はノードを直接変更できません。トランザクションロジックをプロキシに配置することも、プロキシがそのためにカーソルにデリゲートすることもできます。

于 2012-10-01T18:26:43.237 に答える