정의 : 여러 객체가 요청을 처리 할 수있는 기회를 가질 수 있도록하여 요청의 수신자와 수신자 간의 커플 링 관계를 피할 수 있습니다. 이 객체를 체인에 연결하고 객체가 처리 될 때까지 체인을 따라 요청을 전달하십시오.
유형 : 행동 패턴
클래스 다이어그램 :
먼저 코드를 살펴 보겠습니다.
public void test (int i, 요청 요청) {if (i == 1) {handler1.response (request); } else if (i == 2) {handler2.Response (요청); } else if (i == 3) {handler3.Response (요청); } else if (i == 4) {handler4.Response (요청); } else {handler5.Response (요청); }} 코드의 비즈니스 로직은 다음과 같습니다.이 메소드에는 정수 I과 요청 요청이라는 두 가지 매개 변수가 있습니다. 요청을 처리하는 I의 값에 따르면, i == 1이면 handler1에 의해 처리되며 i == 2 인 경우 handler2 등으로 처리됩니다. 프로그래밍에서 이러한 종류의 비즈니스 처리 방법은 매우 일반적입니다. 요청을 처리하는 모든 클래스에는 IF ... ELSE ... 조건부 판단 진술이 요청을 처리하기 위해 책임 체인에 연결된 조건부 판단 진술을 포함합니다. 나는 모두가 종종 그것을 사용한다고 믿는다. 이 방법의 장점은 매우 직관적이고 단순하며 명확하며 유지하기가 쉽지 않지만이 방법은 다음과 같은 두통이 있습니다.
코드 부풀어 오른 코드 : 실제 응용 분야에서 판단 조건은 일반적으로 1 또는 2인지 판단하기가 그렇게 간단하지 않습니다. 복잡한 계산, 데이터베이스 쿼리 등이 필요할 수 있습니다. 여기에는 많은 추가 코드가 있습니다. 많은 판단 조건이 있다면, 이것은 ... 다른 ... 진술은 기본적으로 읽을 수 없습니다.
높은 커플 링 학위 : 프로세스 요청을 계속해서 추가하려면 판단 조건을 계속 추가해야합니다. 또한이 조건의 순서도 죽은 자에게 기록됩니다. 순서를 변경하려면이 조건 명령문 만 수정할 수 있습니다.
우리는 이미 단점을 이해 했으므로이를 해결할 수있는 방법을 찾아야합니다. 이 시나리오의 비즈니스 논리는 매우 간단합니다. 조건 1이 충족되면 handler1에 의해 처리되며 충족되지 않으면 전달됩니다. 조건 2가 충족되면 handler2에 의해 처리되며 충족되지 않으면 조건이 끝날 때까지 전달됩니다. 실제로, 개선 방법은 매우 간단하며, 이는 판단 조건의 일부를 처리 클래스에 넣는 것입니다. 이것이 책임 연결 모델의 원리입니다.
책임 회사 모델의 구조
책임 연결 패턴의 클래스 다이어그램은 매우 간단하며 추상적으로 처리 된 클래스 및 해당 구현 클래스 세트로 구성됩니다.
초록 처리 클래스 : 초록 처리 클래스에는 주로 다음 프로세싱 클래스를 가리키는 멤버 변수 Nexthandler와 요청을 처리하는 메소드 핸드 레퍼스트가 포함됩니다. Handrequest 방법의 주요 아이디어는 처리 조건이 충족되면이 처리 클래스가 처리됩니다. 그렇지 않으면 Nexthandler에 의해 처리됩니다.
특정 처리 클래스 : 특정 처리 클래스는 주로 특정 처리 로직 및 처리를위한 적용 가능한 조건을 구현합니다.
예
책임 모델에는 두 가지 역할이 있습니다.
초록 처리기 역할 : 요청 된 인터페이스를 정의합니다. 필요한 경우 다음 홈 객체에 대한 참조를 설정하고 반환하는 메소드를 정의 할 수 있습니다.
ConcreteHandler 역할 : 처리 할 수있는 경우 요청을 처리하십시오. 처리 할 수없는 경우 요청을 다음 집으로 전달하고 다음 집에서 처리하십시오. 즉, 처리 할 수있는 요청을 처리하고 다음 집에 액세스 할 수 있습니다.
위의 패턴의 테스트 코드는 다음과 같습니다.
패키지 ChainOfResp;/***설명 : 초록 처리 역할*/public Abstract Class handler {보호 된 핸들러 후계자; / ***설명 : 처리 방법*/ public Abstract void handlerRequest (문자열 조건); 공개 처리기 getSuccessor () {return Acccefor; } public void setSuccessor (핸들러 후속 업체) {this.successor = 후속 자; }} 패키지 chainOfResp;/***설명 : 역할의 상세 처리*/public class concreteHandler1 handler {@override public void handlerRequest (문자열 조건) {// 자신의 책임이라면 직접 처리하고 다음 홈으로 전달할 책임이 있습니다 (ConcleteHandler1 ")) {ConcreteDler.println ("ConcreteDler1 "); 반품 ; } else {System.out.println ( "ConcreteHandler1이 통과"); getSuccessor (). handlerRequest (조건); }}} 패키지 chainOfResp;/***설명 : 역할의 상세 처리*/public class concreteHandler2 handler {@override public void handlerRequest (문자열 조건) {// 자신의 책임이라면 직접 처리하고 다음 집으로 전달할 책임이 있습니다 (Conclest.Pequals ( "ConcleteHandler2")) 반품 ; } else {System.out.println ( "ConcreteHandler2가 통과"); getSuccessor (). handlerRequest (조건); }}} 패키지 chainofresp;/*** 설명 : 세부 처리 역할*/public class concretehandlern 확장 핸들러 {/*** 여기서 n은 실제 상황에서 처리 해야하는 체인의 마지막 노드라고 가정합니다.* 반지 또는 트리가 나타날 수 있습니다. */ @override public void handlerRequest (문자열 조건) {System.out.println ( "ConcreteHandlern Handled"); }} 패키지 ChainOfResp;/***설명 : 테스트 클래스*/public class client {/***설명 :*/public static void main (String [] args) {handler handler1 = new ConcreteHandler1 (); 핸들러 핸들러 2 = 새로운 콘크리트 핸들러 2 (); 핸들러 핸들러 = 새로운 콘크리트 핸들러 (); // 체인 핸들러 1.SetSuccessor (handler2); handler2.setsuccessor (핸들러); //이 요청이 ConcreteHandler2 handler1.HandlerRequest ( "ConcreteHandler2")의 책임이라고 가정합니다. }}
이 예를 들어, 장난감 공장의 제작 워크숍에서 조립 라인은 책임의 체인입니다. 장난감 항공기에 쉘 어셈블러, 엔진 어셈블러, 프로펠러 어셈블러 및 모델 패커가있는 경우. 항공기가 물체가 흐르는 사람에게 흐르는 경우, 그는 책임있는 부품을 설치할 책임이 있습니다. 이 부분이 설치되면 다음 단계로 흐르고 모든 환경이 완료되었음을 알 수 있습니다. 이것은 생성되는 책임의 사슬입니다. 또한 품질 검사 체인이 있으며 여러 부품, 쉘 검사, 엔진 검사, 프로펠러 검사 및 포장 검사로 나뉩니다. 제품을 검사관에게 맡기면 책임이있는 조각을 테스트하면 문제가 있으면 직접 꺼집니다. 문제가 없으면 모든 테스트가 완료 될 때까지 다음 검사관에게 전달됩니다. 이 두 사람은 책임의 사슬이지만 차이점은 모든 사람이 책임의 사슬을 처리하고 그 일부를 처리한다는 것입니다. 판단 후에는 품질 검사에 대한 책임의 사슬이 처리되거나 처리되지 않습니다. 이것들은 책임 체인의 두 가지 범주입니다. 후자는 순수한 책임 체인이라고하며, 전자는 불순한 책임 체인이라고합니다. 순수한 책임 체인은 실제 응용에 거의 존재하지 않습니다. 일반적인 것은 불순한 책임 체인입니다. 위의 모델은 처리 할 순수한 책임 체인을 시뮬레이션합니다.
책임 체인 모델의 장단점
IF… 다른…와 비교하여, 책임 체인 패턴은 조건부 판단을 다양한 처리 클래스에 분배하기 때문에 더 낮은 커플 링 능력을 갖고 있으며, 이러한 처리 클래스의 우선 순위 처리 순서는 마음대로 설정할 수 있습니다. 책임 체인 모델에는 또한 IF ... ELSE ... 진술, 즉 올바른 처리 클래스를 찾기 전에 모든 판단 조건을 실행 해야하는 것과 동일합니다. 책임 체인이 비교적 길면 성능 문제가 더 심각합니다.
책임 모델에 대한 적용 가능한 시나리오
처음 예제와 마찬가지로, if… else… 진술을 사용할 때 압도적이라고 느끼면 책임 체인을 구성하고 코드가 나빠 보이면 책임 모드를 사용하여 리팩터링 할 수 있습니다.
요약
책임 체인 모델은 실제로 IF ... Else ... 문의 유연한 버전입니다. 이러한 판단 조건을 각 처리 클래스에 넣습니다. 이것의 장점은 더 유연하지만 위험을 초래한다는 것입니다. 예를 들어, 처리 클래스 전후에 처리 클래스 간의 관계를 설정할 때 처리 클래스 전후에 조건부 논리 간의 관계를 판단하고 체인에서 순환 참조를하지 않도록주의해야합니다.