책임 정의 : COR (Chain of Response)는 요청을 처리하는 일련의 클래스입니다. 다시 말해서, 요청이 오면, 클래스 A가 처리되지 않으면 클래스 B 프로세스에 전달되면 Class C 프로세스로 전달됩니다.
책임 모델을 사용하는 방법
이 단락은 Cor를 사용하지만 Cor가 무엇인지 보여줍니다.
핸들러 인터페이스가 있습니다.
코드 사본은 다음과 같습니다.
공개 인터페이스 핸들러 {
public void handlerequest ();
}
이것은 요청을 처리하거나 요청하는 것과 같은 여러 요청이있는 경우 다음과 같은 요청을 처리합니다.
◆ 가장 먼저 떠오르는 솔루션은 다음과 같습니다. 인터페이스에 여러 요청을 추가합니다.
코드 사본은 다음과 같습니다.
공개 인터페이스 핸들러 {
공개 void handleHelp ();
public void handlePrint ();
public void handleformat ();
}
특히 인터페이스를 구현하는 코드입니다.
코드 사본은 다음과 같습니다.
공개 클래스 ConcreteHandler는 핸들러를 구현합니다.
개인 처리기 후임자;
공개 콘크리트 핸들러 (핸들러 후속 인) {
this.successor = 후임자;
}
public void handleHelp () {
// 도움말 요청 처리를위한 특정 코드 ...
}
public void handlePrint () {
// 인쇄 인 경우 프로세스 인쇄로 전환하십시오
후계자 핸들 프린트 ();
}
public void handleformat () {
// 형식 인 경우 프로세스 형식으로 이동하십시오
후계자 handleFormat ();
}
}
위의 세 가지 특정 구현 클래스는 처리 도움말을 처리하고 인쇄 및 처리 형식을 처리합니다. 이는 아마도 가장 일반적으로 사용되는 프로그래밍 아이디어 일 것입니다.
아이디어는 간단하고 명확하지만 다른 요청 유형을 추가 해야하는 경우 인터페이스와 각 구현을 수정해야합니다.
◆ 두 번째 솔루션 : 각 요청을 인터페이스로 바꾸므로 다음 코드가 있습니다.
코드 사본은 다음과 같습니다.
공개 인터페이스 helphandler {
공개 void handleHelp ();
}
공개 인터페이스 프린트 칸 더 러 {
public void handlePrint ();
}
공개 인터페이스 Formathandler {
public void handleformat ();
}
공개 클래스 콘크리트 핸들러
HelpHandler, Printhandler, Formathandlet {
개인 헬프 핸들러 helpuccessor;
개인 프린트 칸 더 러 인쇄 소자;
개인 Formathandler Formatsuccessor;
Public ConcreteHandler (HelpHandler HelpUccessor, Printhandler Printsuccessor, Formathandler Formatsuccessor)
{
this.helpsuccessor = helpuccessor;
this.printsuccessor = printsuccessor;
this.formatsuccessor = formatsuccessor;
}
public void handleHelp () {
.........
}
public void handlprint () {this.printsuccessor = printsuccessor;}
public void handleformat () {this.formatsuccessor = formatsuccessor;}
}
새 요청 요청을 추가 할 때이 메소드는 인터페이스의 수정량 만 저장되며 ConcreteHandler의 인터페이스 구현도 수정해야합니다. 그리고 코드는 분명히 단순하고 아름답 지 않습니다.
◆ 솔루션 3 : 핸들러 인터페이스에는 하나의 매개 변수화 방법 만 사용됩니다.
코드 사본은 다음과 같습니다.
공개 인터페이스 핸들러 {
공개 void handlerequest (문자열 요청);
}
그런 다음 핸들러 구현 코드는 다음과 같습니다.
공개 클래스 ConcreteHandler는 핸들러를 구현합니다.
개인 처리기 후임자;
공개 콘크리트 핸들러 (핸들러 후속 인) {
this.successor = 후임자;
}
public void handlerequest (문자열 요청) {
if (request.equals ( "help")) {
// 여기에 도움말을 처리하기위한 특정 코드} else
// 다음 후계자에게 전달됩니다. handle (요청);
}
}
}
먼저 요청이 문자열 유형이라고 가정 해 봅시다. 물론 우리는 특별 수업 요청을 만들 수 있습니다
◆ 최종 솔루션 : 인터페이스 핸들러의 코드는 다음과 같습니다.
코드 사본은 다음과 같습니다.
공개 인터페이스 핸들러 {
공개 void handlerequest (요청 요청);
}
요청 클래스의 정의 :
공개 클래스 요청 {
개인 문자열 유형;
공개 요청 (문자열 유형) {this.type = type;}
공개 문자열 getType () {return type;}
public void execute () {
// 실제 특정 행동 코드의 요청}
}
그런 다음 핸들러 구현 코드는 다음과 같습니다.
코드 사본은 다음과 같습니다.
공개 클래스 ConcreteHandler는 핸들러를 구현합니다.
개인 처리기 후임자;
공개 콘크리트 핸들러 (핸들러 후속 인) {
this.successor = 후임자;
}
public void handlerequest (요청 요청) {
if (helpRequest의 요청 인스턴스) {
// 여기에 도움말을 처리하기위한 특정 코드는 다음과 같습니다.} else if (PrintRequest의 요청) {
request.execute ();
}또 다른
// 다음 후계자에게 전달됩니다. handle (요청);
}
}
}
이 솔루션은 COR입니다. 체인에 대한 책임은 해당 책임이 있으므로 책임 체인이라고합니다.
1. COR의 장점 : 외부 세계의 요청 유형의 요청을 예측하는 것은 불가능하기 때문에, 각 클래스가 처리 할 수없는 요청을 만나면 포기하는 경우. 이것은 의심 할 여지없이 클래스 간의 결합을 줄입니다.
2. COR의 단점은 비효율적입니다. 요청의 완료는 물론 끝날 때까지 트리의 개념을 사용하여 최적화 할 수 있기 때문입니다. Java AWT1.0에서는 마우스 버튼의 처리는 Java.1.1을 사용하는 것입니다.
COR에는 통합 인터페이스 핸들러가 있어야하므로 확장 성이 좋지 않습니다.