트리 구조와 다른 노드 유형에 대한 방문자 패턴의 사용법을 수정하고 싶습니다. 트리 구조의 모든 노드는 콜백 메소드를 구현해야하고 방문자 구현은 (적어도 그가에 관심있는 유형 또는) 각 노드 유형에 대해 다음과 같이 구현해야합니다트리 구조의 방문객 패턴
/**
* 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);
}
커서 클래스가 노드를 프록시로 감쌀 수 있습니다. 그러면 노드와 동일한 인터페이스가 방문자에게 노출됩니다. 그러면 어떤 방문자도 노드를 직접 수정할 수 없습니다. 트랜잭션 로직을 프록시에 넣거나 프록시가 프록시 로직에 위임 할 수 있습니다. – nansen
예를 들어, 생성자에서 수정 가능한 인스턴스를 예상하는 각 노드 유형에 대한 불변의 "래퍼"또는 프록시를 제공합니까? 좋은 아이디어 :-) – Johannes
@nansen, 해설이 대답으로 바뀌 었는지 확인하십시오. – MvG