디자인 모델 의 일부분 (Visitor 방문 자 모델)

개발 과정 에서 우 리 는 고객 이 새로운 수 요 를 제기 하 는 것 을 자주 만 날 수 있 습 니 다. 그러면 기 존의 유형 에서 새로운 수 요 를 실현 할 수 있 습 니까?일반적인 방법 은 새로운 방법 을 추가 하 는 것 이다.그러나 때때로 우 리 는 인터페이스 만 볼 수 있 을 뿐 인터페이스 가 실현 되 는 것 을 전혀 볼 수 없다.이 럴 때 우 리 는 인터페이스 에 연결 하 는 방법 을 추가 할 수 없다.하지만 개발 자가 얼마나 디자인 할 수 있 을 때 Visitor 모델 을 사용 하면 결 과 는 크게 다르다.
 
Visitor 모드 는 코드 사용자 가 기 존의 계층 구 조 를 수정 하지 않 은 상태 에서 이러한 계층 구 조 를 정의 할 수 있 도록 하 는 작업 입 니 다.
예:
  방문 자 모드 에 관 한 JE 에는 사례 가 많 았 고 논란 도 컸 다.다음은 흔히 볼 수 있 는 Visitor 모델 의 예 를 들 어 벽돌 을 찍 는 것 을 환영 합 니 다.
 
예 를 들 어 한 회사 에 사장, 매니저, 직원 등 세 가지 역할 이 있 는데 모든 역할 은 Human 과 같은 유형 을 계속 한다. Human 과 같은 유형 에 대해 우 리 는 추상 적 인 것 으로 정의 한다.

public abstract class Human {
	protected int id;
	//         ，              
	protected List<? extends Human> list = new ArrayList<Human>();

	public List<? extends Human> getList() {
		return list;
	}

	public void setList(List<? extends Human> list) {
		this.list = list;
	}

	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

	public  void accept(Visitor visitor){
		
	}
}

 
 
그 세 가지 역할 은 모두 이 Human 류 를 계속 합 니 다.

public class Boss extends Human {
	public Boss(int id){
		this.id = id;
	}
	@Override
	public void accept(Visitor visitor) {
		visitor.visit(this);
	}
	public String toString(){
		return new StringBuffer("Manager the id:"+id).toString();
	}
}

public class Manager extends Human {
	public Manager(int id){
		this.id = id;
	}
	@Override
	public void accept(Visitor visitor) {
		visitor.visit(this);
	}
	public String toString(){
		return new StringBuffer("Manager the id:"+id).toString();
	}
}


public class Employee extends Human{
	public  Employee(int id){
		this.id = id;
	}
	@Override
	public void accept(Visitor visitor) {
		visitor.visit(this);
	}
	
	public String toString(){
		return new StringBuffer("Employee the id:"+id).toString();
	}

}

 
 
 
우리 가 이 회사 의 구성원 들 을 구성 할 때 나 는 다음 과 같은 방법 으로 구 조 를 가설 했다.

Boss boss = new Boss(1);
		List<Manager> managers = new ArrayList<Manager>();
		for(int i =2;i<10;i++){
			Manager manager = new Manager(i);
			List<Employee> employees = new ArrayList<Employee>();
			int k = i*10;
			for(int j = k;j<k+8;j++){
				employees.add(new Employee(j));
			}
			manager.setList(employees);
			managers.add(manager);
		}
		boss.setList(managers);

 
그래서 이때 저 는 직원 번호 가 20 인 직원 에 대한 정 보 를 조회 하고 싶 습 니 다. 물론 저 는 Boss 부터 시작 해서 그의 List 목록 과 하위 목록 을 옮 겨 다 닐 수 있 습 니 다.다음 과 같이 구현:

	public static Human getHuman(Human human, int id) {
		if (human.getId() != id) {
			List<Human> ms = (List<Human>) human.getList();
			for (Human h : ms) {
				if(getHuman(h,id)!=null){
					return getHuman(h,id);
				}else{
					return null;
				}
			}
			return null;
		} else {
			return human;
		}
	}

 
그러나 우 리 는 방문 자 모드 로 그것 을 실현 하고 싶 어서 방문 자 인 터 페 이 스 를 정의 합 니 다.

/**
 *       
 * @author Administrator
 *
 */
public interface Visitor {
 public void visit(Employee employee);
 public void visit(Human human);
}

 
인 터 페 이 스 는 다음 과 같 습 니 다.

public class FindVisitor implements Visitor{
	private int soughtId;
	private Human found;
	public void visit(Employee employee) {
		if(found==null&&employee.getId()==soughtId){
			found=employee;
		}
	}
	public void visit(Human human) {
		if(found==null&&human.getId()==soughtId){
			found=human;
			return;
		}
		List<? extends Human> list = human.getList();
		for(Human e:list){
			if(found==null)
			e.accept(this);
		}
	}
	public Human find(Human mc,int id){
		found = null;
		soughtId = id;
		mc.accept(this);
		return found;
	}
	
}

 
다음은 간단 한 테스트 를 해 보 겠 습 니 다.

FindVisitor fv =new FindVisitor();
Human human = fv.find(boss, 20);
System.out.println("find:"+ human);

 
소결:
   방문 자 모델 은 우리 로 하여 금 클래스 구조 중의 클래스 를 바 꾸 지 않 는 상황 에서 이러한 차원 구조 에 새로운 조작 을 정의 하 게 할 수 있다.위의 예 를 들 어 새로운 수 요 를 추가 하려 면 직원 번 호 를 찾 고 직원 정 보 를 수정 하려 면 인터페이스 방법 을 추가 하고 실현 을 추가 할 수 있 습 니 다.클래스 계층 구조 에 접근 기 를 추가 하면 accept () 방법 을 호출 합 니 다. accept () 방법 은 '두 번 분리' 기술 을 사용 하여 호출 결 과 를 방문 자 클래스 에 되 돌려 줍 니 다. visit () 방법 은 방문 자 클래스 에 정의 되 며, 클래스 계층 구조 중의 특정한 대상 은 그 유형 에 따라 적합 한 visti () 방법 을 호출 할 수 있 습 니 다.
 
   방문 자 류 의 개발 자 들 은 방문 할 클래스 구조의 전부 또는 일부 디자인 디 테 일 을 잘 알 아야 합 니 다. 또한 방문 자 류 를 디자인 할 때 방문 대상 모델 에 고리 구조 가 나타 날 수 있 음 을 특히 주의해 야 합 니 다. 이러한 문 제 를 고려 하여 일부 개발 자 들 은 방문 자의 틀 을 바 꾸 는 것 을 피 하려 고 합 니 다. 습관 적 으로 다른 방안 을 사용 하여 교체 해 야 합 니 다.일반적으로 소프트웨어 개발 팀 은 자신 이 사용 하 는 소프트웨어 개발 방법론 에 따라 프로젝트 팀 과 구체 적 인 프로젝트 의 구체 적 인 상황 에 따라 방문 자 모델 을 사용 해 야 한다.