23 가지 디자인 모델 (22)행동 형책임 체인 모드 (책임 패턴 의 체인)

정의: 여러 대상 이 요청 을 처리 할 수 있 도록 요청 한 발송 자 와 수신 자 간 의 결합 관 계 를 피 할 수 있 습 니 다.이 대상 들 을 하나의 체인 으로 연결 하고 이 체인 을 따라 이 요 구 를 전달 하 며 대상 이 처리 할 때 까지 합 니 다.
유형: 행동 유형
아 날로 그:
먼저 코드 를 살 펴 보 겠 습 니 다.

public void test(int i, Request request){
    if(i==1){
        Handler1.response(request);
    }else if(i == 2){
        Handler2.response(request);
    }else if(i == 3){
        Handler3.response(request);
    }else if(i == 4){
        Handler4.response(request);
    }else{
        Handler5.response(request);
    }
}

코드 의 비 즈 니스 논 리 는 이 렇 습 니 다. 방법 은 두 가지 매개 변수 가 있 습 니 다. 정수 i 와 하나의 요청 request 는 i 의 값 에 따라 누가 request 를 처리 할 지 결정 합 니 다. 만약 i = 1 이면 Handler 1 이 처리 하고 i = = 2 이면 Handler 2 가 처리 합 니 다.프로 그래 밍 에서 이런 업 무 를 처리 하 는 방법 은 매우 흔히 볼 수 있 습 니 다. 모든 처리 요청 의 종 류 는 if.. else... 조건 판단 문 구 를 하나의 책임 체인 으로 연결 하여 요청 을 처리 합 니 다. 모두 가 자주 사용 할 것 이 라 고 믿 습 니 다.이런 방법의 장점 은 매우 직관 적 이 고 간단명료 하 며 유지 하기 쉽다 는 것 이다. 그러나 이런 방법 에 도 비교적 골 치 아 픈 문제 가 존재 한다.
코드 비대: 실제 응용 에서 의 판정 조건 은 보통 이렇게 간단하게 1 인지 아 닌 지 를 판단 하지 않 습 니 다. 복잡 한 계산 이 필요 할 수도 있 고 데이터 베 이 스 를 조회 해 야 할 수도 있 습 니 다. 이것 은 추가 코드 가 많 습 니 다. 만약 에 판단 조건 이 더 많 으 면 이 if.. else.. 문 구 는 기본적으로 볼 수 없습니다
결합 도가 높 음: 요청 을 처리 하 는 클래스 를 계속 추가 하려 면 else if 판정 조건 을 계속 추가 해 야 합 니 다.또 이 조건 판정 순서 도 죽 었 다. 순 서 를 바 꾸 려 면 이 조건 문 구 를 수정 할 수 밖 에 없다
기왕 결점 을 우리 가 이미 알 았 으 니 방법 을 강구 해서 해결 해 야 한다.이 장면 의 업무 논 리 는 매우 간단 하 다. 만약 에 조건 1 을 만족 시 키 면 Handler 1 이 처리 하고 만족 하지 않 으 면 아래로 전달한다.조건 2 가 충족 되면 Handler 2 가 처리 하고, 만족 하지 않 으 면 조건 이 끝 날 때 까지 계속 아래로 전달 하 는 식 으로 유추 된다.사실 개선 하 는 방법 도 간단 하 다. 판정 조건 의 부분 을 처리 류 에 넣 는 것 이 책임 연결 모델 의 원리 다.
 
책임 체인 모델 의 구조
책임 체인 모델 의 유형 도 는 매우 간단 하 다. 이 는 추상 적 인 처리 류 와 그의 실현 류 로 구성 된다.
추상 처리 클래스: 추상 처리 클래스 에는 다음 처리 클래스 를 가리 키 는 구성원 변수 nextHandler 와 요청 을 처리 하 는 방법 handRequest 가 포함 되 어 있 습 니 다. handRequest 방법의 주요 사상 은 처리 조건 을 만족 시 키 면 본 처리 클래스 가 처리 되 고 그렇지 않 으 면 nextHandler 가 처리 하 는 것 입 니 다
구체 적 인 처리 유형: 구체 적 인 처리 유형 은 주로 구체 적 인 처리 논리 와 처리 의 적용 조건 을 실현 하 는 것 이다
책임 연결 모델 의 대체적인 사상 을 이해 한 후에 코드 를 보면 이해 하기 쉽다.

class Level {
    private int level = 0;
    public Level(int level){
        this.level = level;
    };
 
    public boolean above(Level level){
        if(this.level >= level.level){
            return true;
        }
        return false;
    }
}
 
class Request {
    Level level;
    public Request(Level level){
        this.level = level;
    }
 
    public Level getLevel(){
        return level;
    }
}
 
class Response {
 
}
 
abstract class Handler {
    private Handler nextHandler;    
    public final Response handleRequest(Request request){
        Response response = null;
 
        if(this.getHandlerLevel().above(request.getLevel())){
            response = this.response(request);
        }else{
            if(this.nextHandler != null){
                this.nextHandler.handleRequest(request);
            }else{
                System.out.println("-----        -----");
            }
        }
        return response;
    }
    public void setNextHandler(Handler handler){
        this.nextHandler = handler;
    }
    protected abstract Level getHandlerLevel();
    public abstract Response response(Request request);
}
 
class ConcreteHandler1 extends Handler {
    protected Level getHandlerLevel() {
        return new Level(1);
    }
    public Response response(Request request) {
        System.out.println("-----      1    -----");
        return null;
    }
}
 
class ConcreteHandler2 extends Handler {
    protected Level getHandlerLevel() {
        return new Level(3);
    }
    public Response response(Request request) {
        System.out.println("-----      2    -----");
        return null;
    }
}
 
class ConcreteHandler3 extends Handler {
    protected Level getHandlerLevel() {
        return new Level(5);
    }
    public Response response(Request request) {
        System.out.println("-----      3    -----");
        return null;
    }
}
 
public class Client {
    public static void main(String[] args){
        Handler handler1 = new ConcreteHandler1();
        Handler handler2 = new ConcreteHandler2();
        Handler handler3 = new ConcreteHandler3();
 
        handler1.setNextHandler(handler2);
        handler2.setNextHandler(handler3);
 
        Response response = handler1.handleRequest(new Request(new Level(4)));
    }
}

코드 에서 Level 류 는 아 날로 그 판정 조건 입 니 다.Request, Response 는 각각 요청 과 응답 에 대응 합 니 다.추상 클래스 Handler 에 서 는 주로 조건 판단 을 하 는데 여기 서 처리 등급 을 모 의 한 것 으로 처리 등급 이 Request 등급 보다 높 아야 처리 할 수 있 으 며 그렇지 않 으 면 다음 처리 자 에 게 맡 길 수 있 습 니 다.Client 클래스 에 체인 의 앞 뒤 실행 관 계 를 설정 하고 실행 할 때 첫 번 째 처리 클래스 에 요청 을 맡 깁 니 다. 이것 이 바로 책임 연결 모드 입 니 다. 완 성 된 기능 은 앞의 if.. else.. 문장 과 같 습 니 다.
책임 체인 모델 의 장단 점
책임 체인 모드 는 if... else... 에 비해 그의 결합 성 이 낮 습 니 다. 조건 판단 을 각 처리 류 에 분산 시 켰 고 이런 처리 류 의 우선 처리 순 서 는 마음대로 설정 할 수 있 기 때 문 입 니 다.책임 체인 모델 도 단점 이 있 습 니 다. 이것 은 if.. else.. 문장의 단점 과 같 습 니 다. 그것 은 바로 정확 한 처리 류 를 찾기 전에 모든 판정 조건 이 한 번 집행 되 어야 합 니 다. 책임 체인 이 비교적 길 때 성능 문제 가 비교적 심각 합 니 다.
 
책임 체인 모드 의 적용 장면
시작 하 는 예 와 같이 if... else... 문 구 를 사용 하여 책임 체인 을 구성 할 때 힘 이 부 족 스 럽 고 코드 가 엉망 으로 보일 때 책임 체인 모델 로 재 구성 할 수 있 습 니 다.
총결산
책임 체인 모델 은 바로 유연 한 버 전의 if... else.. 문 구 는 바로 이러한 판정 조건 의 문 구 를 각 처리 류 에 넣 는 것 이다. 이렇게 하 는 장점 은 비교적 유연 하지만 위험 도 가 져 왔 다. 예 를 들 어 처리 류 의 전후 관 계 를 설정 할 때 반드시 자세히 처리 류 의 전후 논리 적 조건 에 대한 판단 관 계 를 해 야 한다.또한 체인 에서 순환 인용 문제 가 발생 하지 않도록 주의 하 세 요.