2012-10-01 2 views
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-방법을 제공하는 의미를 커서, 그게 내가 다음 구현 한 커서에 있습니다

노드 자체를 노출하기 때문에 방문자는 API의 결함이다 그러나
@Override 
public EVisitResult acceptVisitor(final @Nonnull IVisitor pVisitor) { 
    assertNotClosed(); 
    return mCurrentNode.acceptVisitor(pVisitor); 
} 

, 예를 들어 ElementNode은 매우 위험합니다. 왜냐하면 모든 노드 -t ype는 특정 쓰기 트랜잭션 내에서만 가능해야합니다 (트리 구조를 트래버스하는 메소드를 제공하는 커서로 구현 됨). 그렇지 않은 경우 변경 내용은 표시되지 않으며 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); 
} 
+1

커서 클래스가 노드를 프록시로 감쌀 수 있습니다. 그러면 노드와 동일한 인터페이스가 방문자에게 노출됩니다. 그러면 어떤 방문자도 노드를 직접 수정할 수 없습니다. 트랜잭션 로직을 프록시에 넣거나 프록시가 프록시 로직에 위임 할 수 있습니다. – nansen

+0

예를 들어, 생성자에서 수정 가능한 인스턴스를 예상하는 각 노드 유형에 대한 불변의 "래퍼"또는 프록시를 제공합니까? 좋은 아이디어 :-) – Johannes

+0

@nansen, 해설이 대답으로 바뀌 었는지 확인하십시오. – MvG

답변

2

당신에게 : 나는 어떻게 든

좋아, 내가 불변 "래퍼"또는 프록시 클래스를 제공 할 것입니다 ... 내가 다를 수 있는지에 대한 방법 서명으로 방문자 인터페이스를 제공 할 수있어 의심 커서 클래스가 노드를 프록시와 함께 랩 (wrapping)하여 노드와 동일한 인터페이스를 방문자에게 노출시킬 수 있습니다. 그러면 어떤 방문자도 노드를 직접 수정할 수 없습니다. 트랜잭션 로직을 프록시에 넣거나 프록시가 프록시 로직에 위임 할 수 있습니다.

관련 문제