iOS 응용 디자인 모델 개발 중 직 책임 체인(책임 체인)모델 의 실현 분석
요청 발송 자 와 수신 자가 결합 하 는 것 을 피하 기 위해 여러 대상 이 요청 을 받 을 수 있 도록 이 대상 을 하나의 체인 으로 연결 하고 이 체인 을 따라 요청 을 전달 합 니 다.대상 이 처리 할 때 까지 직책 체인 모델 은 책임 체인 모델 이 라 고도 부 르 는데 이것 은 대상 행위 형 모델 입 니 다.(만약 당신 이 이상 처 리 를 접 한 적 이 있다 면,이상 처리 체 제 를 사용 하면 더욱 잘 이해 할 수 있 습 니 다.
직책 체인 은 직선 일 수도 있 고 고리 일 수도 있 으 며 나무 구조 일 수도 있 지만 가장 흔히 볼 수 있 는 직책 체인 은 직선 형 이다.즉,단 방향 체인 을 따라 요 구 를 전달 하 는 것 이다.체인 의 모든 대상 은 요청 처리 자 입 니 다.직책 체인 모델 은 요청 한 처리 자 를 하나의 체인 으로 구성 하고 요청 을 체인 을 따라 전달 할 수 있 습 니 다.체인 의 처리 자가 요청 에 대해 해당 하 는 처 리 를 할 수 있 습 니 다.클 라 이언 트 는 요청 의 처리 세부 사항 과 요청 의 전달 에 관심 을 가지 지 않 고 요청 을 체인 에 보 내 면 됩 니 다.이러한 방법 을 통 해 요청 한 발송 자 와 요청 한 처리 자 를 결합 시 켜 두 캐릭터 간 의 의존 관 계 를 없 애고 자 유 롭 게 조합 할 수 있 습 니 다.
원리 구조
위의 그림 에서 설명 한 것 은 직책 연결 모델 의 실현 원리 이 고 주요 역할 은 다음 과 같다.
Handler:추상 적 인 처리 자.요청 을 처리 하 는 인 터 페 이 스 를 정의 합 니 다.필요 하 다 면 인 터 페 이 스 는 다음 인용 을 설정 하고 되 돌려 주 는 방법 을 정의 할 수 있 습 니 다.이 역할 은 보통 추상 적 인 유형 이나 인터페이스 로 이 루어 진다.
Concrete Handler:구체 적 인 처리 자.구체 적 인 처리 자 는 요청 을 받 은 후 요청 을 처리 하거나 요청 을 다음 집에 전달 할 수 있다.구체 적 인 처리 자 는 다음 집에 대한 인용 을 가지 고 있 기 때문에 필요 하 다 면 구체 적 인 처리 자 는 다음 집 을 방문 할 수 있다.
클 라 이언 트:클 라 이언 트
handle Request:추상 적 인 처리 자의 공용 인 터 페 이 스 는 모든 체인 노드 가 이 인 터 페 이 스 를 실현 하도록 요구 하고 클 라 이언 트 가 보 낸 요청 데 이 터 를 처리 할 수 있 습 니 다.
모든 체인 노드 에 대해 두 가지 조건 을 만족 시 켜 야 한다.
추상 적 인 처리 자(Handler)가 정의 하 는 추상 적 인 인 터 페 이 스 를 실현 하여 받 은 요 구 를 식별 할 수 있다.
현재 처리 할 수 없 는 요청 을 다음 노드 로 전송 하 는 데 사용 되 는 successor 가 있 습 니 다.그래 야 체인 이 생 길 수 있 습 니 다.(successor 는 다음 ConcreteHandler 의 인용 을 말 하 는데 링크 안의 next 지침 에 해당 합 니 다)
상기 프로 그래 밍 디자인 을 통 해 요청 과 이 요 구 를 처리 하 는 대상 은 의존 관계 가 전혀 없다.클 라 이언 트 는 누가 이 요 구 를 처 리 했 는 지 모 르 기 때문에 전체 체인 구조 가 유연 하고 수시로 새로운 노드 를 추가 할 수 있다.물론 노드 순 서 를 임의로 조절 하고 불필요 한 노드 를 삭제 하 는 등 작업 도 지원 한다.
iOS 구현
직책 체인 모델 의 중요 한 특징 은 고객 이 요 구 를 한 후에 클 라 이언 트 는 어느 대상 이 이 요 구 를 최종 적 으로 처리 하 는 지 모른다 는 것 이다.그러면 시스템 의 변경 은 클 라 이언 트 에 영향 을 주지 않 는 상황 에서 동태 적 으로 책임 을 재 구성 하고 분배 할 수 있다.
다음은 클래스 구성 도 를 드 리 겠 습 니 다.
위의 그림 에서 알 수 있 듯 이 고객 이 요청 을 제출 할 때 요청 은 하나의 Concrete Handler 대상 이 처리 할 때 까지 체인 을 따라 전달 하 는 것 이다.이렇게 하 는 장점 은 청구 자 는 어떤 대상 이 처리 하 든 상관 하지 않 아 도 된다 는 것 이다.어쨌든 결국 어떤 대상 에 게 처리 되 어야 한다.즉,수신 자 와 발송 자 모두 상대방 의 명확 한 정보 가 없고 체인 중의 대상 자신 도 체인 의 구 조 를 모른다 는 것 이다.결 과 는 직책 체인 이 대상 의 상호 연결 을 간소화 할 수 있다 는 것 이다.그들 은 후계 자 를 가리 키 는 인용 만 유지 하고 모든 후보 수용자 의 인용 을 유지 할 필요 가 없다.
이러한 특징의 장점 은 우리 가 요청 한 구 조 를 수시로 증가 하거나 수정 할 수 있다 는 것 이다.대상 에 게 직책 을 할당 하 는 유연성 을 강화 했다.그러나 하나의 요청 이 체인 의 끝 에 이 르 러 처리 되 지 못 하거나 정확 한 설정 이 없어 서 처리 되 지 못 할 가능성 이 높 기 때문에 우리 가 사전에 전면적으로 고려 해 야 한다.
네,이렇게 많은 말 을 했 는데 도 그대로 입 니 다.간단 한 안내 코드 를 보 여 드 리 겠 습 니 다.
주의:본 논문 의 모든 코드 는 ARC 환경 에서 컴 파일 되 었 습 니 다.
Handlers 클래스 인터페이스
#import <Foundation/Foundation.h>
@interface Handlers :NSObject{
Handlers *mySuccessor;
}
-(void)SetSuccessor:(Handlers*)successor;
-(void)HandleRequest:(int)request;
@end
#import "Handlers.h"
@implementation Handlers
-(void)SetSuccessor:(Handlers *)successor{
mySuccessor = successor;
}
-(void)HandleRequest:(int)request{
return;
}
@end
#import "Handlers.h"
@interface ConcreteHandler1:Handlers
-(void)HandleRequest:(int)request;
@end
ConcreteHandler1
#import "ConcreteHandler1.h"
@implementation ConcreteHandler1
-(void)HandleRequest:(int)request{
if (request >=0 && request <10) {
NSLog(@"ConcreteHandler1 %d", request);
}
else if (mySuccessor !=nil) {
[mySuccessor HandleRequest:request];
}
}
@end
#import "Handlers.h"
@interface ConcreteHandler2 :Handlers
@end
#import "ConcreteHandler2.h"
@implementation ConcreteHandler2
-(void)HandleRequest:(int)request{
if (request >=10 && request <20) {
NSLog(@"ConcreteHandler2 %d", request);
}
else if(mySuccessor !=nil) {
[mySuccessor HandleRequest:request];
}
}
@end
#import "Handlers.h"
@interface ConcreteHandler3 :Handlers
@end
#import "ConcreteHandler3.h"
@implementation ConcreteHandler3
-(void)HandleRequest:(int)request{
if (request >=20 && request <30) {
NSLog(@"ConcreteHandler3 %d", request);
}
else if (mySuccessor !=nil) {
[mySuccessor HandleRequest:request];
}
}
@end
#import <Foundation/Foundation.h>
int main(int argc,const char * argv[])
{
@autoreleasepool{
Handlers *h1 = [[ConcreteHandler1 alloc]init];
Handlers *h2 = [[ConcreteHandler2 alloc]init];
Handlers *h3 = [[ConcreteHandler3 alloc]init];
[h1 SetSuccessor:h2];
[h2 SetSuccessor:h3];
int requests[] = {2,5,14,22,18,3,27,20};
for (int i =0; i <8; i++) {
[h1 HandleRequest:requests[i]];
}
}
return 0;
}
작은 매듭
행위 형 모델 은 서로 다른 대상 간 에 책임 과 알고리즘 을 구분 하 는 추상 화 이다.행위 형 모델 은 유형 과 대상 의 구조 에 관심 을 가 질 뿐만 아니 라 이들 간 의 상호작용 에 도 중심 을 둔다.행위 형 모델 을 통 해 분류 와 대상 의 직책 을 더욱 명확 하 게 구분 하고 시스템 이 실 행 될 때 실례 대상 간 의 상호작용 을 연구 할 수 있다.행위 형 모델 은 유형 행위 형 모델 과 대상 행위 형 모델 두 가지 로 나 눌 수 있다.직책 체인 모델 은 요청 발송 자 와 수신 자가 결합 하 는 것 을 피 할 수 있 고 여러 대상 이 요청 을 받 을 수 있 도록 합 니 다.이 대상 을 하나의 체인 으로 연결 하고 이 체인 을 따라 요청 을 전달 합 니 다.대상 이 처리 할 때 까지 대상 행위 형 모델 입 니 다.
우리 가 일상적으로 사용 하 는 과정 에서 우 리 는 이 방면 을 직접 접 할 기회 가 많 지 않 을 지도 모른다.그러나 만약 에 네가 프로그램의 처리 메커니즘 을 진지 하 게 연구 한 적 이 있다 면 이런 처리 메커니즘 은 바로 직책 체인 의 방식 으로 프로그램 에서 던 진 이상 한 오 류 를 처리 하 는 것 을 발견 할 수 있다.
재직 책임 체인 모델 에서 많은 대상 이 모든 대상 이 다음 집에 대한 인용 으로 연결 되 어 하나의 체인 을 형성한다.체인 의 한 대상 이 이 요청 을 처리 하기 로 결정 할 때 까지 이 체인 에 전달 해 달라 고 요청 합 니 다.이 요청 을 보 낸 클 라 이언 트 는 체인 의 어느 대상 이 이 요 구 를 최종 적 으로 처리 하 는 지 모 르 기 때문에 시스템 은 클 라 이언 트 에 영향 을 주지 않 는 상황 에서 체인 을 동적 으로 재 구성 하고 책임 을 분배 할 수 있다.
직책 체인 모델 의 주요 장점 은 시스템 의 결합 도 를 낮 추고 대상 의 상호 연결 을 간소화 하 는 동시에 대상 에 게 직책 을 할당 하 는 유연성 을 강화 하고 새로운 요구 처리 류 를 증가 하 는 것 도 편리 하 다 는 것 이다.그 주요 단점 은 요청 이 반드시 받 아들 여 질 것 이 라 고 보장 할 수 없고 비교적 긴 직책 체인 에 대해 요청 한 처 리 는 여러 개의 처리 대상 과 관련 될 수 있 으 며 시스템 성능 이 어느 정도 영향 을 받 을 뿐만 아니 라 코드 디 버 깅 을 할 때 불편 하 다 는 것 이다.
장점:
결합 도 를 낮추다.
대상 의 상호 연결 을 간소화 할 수 있다.
대상 에 게 직책 을 할당 하 는 유연성 을 강화 하 다.
새로운 요청 처리 클래스 를 추가 하 는 것 이 편리 합 니 다.
단점:
요청 이 반드시 받 아들 여 질 것 이 라 고 장담 할 수 없다.
시스템 성능 은 일정한 영향 을 받 을 뿐만 아니 라 코드 디 버 깅 을 할 때 불편 하 다(순환 호출 을 초래 할 수 있다).
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
View의 레이아웃 방법을 AutoLayout에서 따뜻한 손 계산으로 하면 성능이 9.26배로 된 이야기이 기사는 의 15 일째 기사입니다. 어제는 에서 이었습니다. 손 계산을 권하는 의도는 없고, 특수한 상황하에서 계측한 내용입니다 화면 높이의 10 배 정도의 contentView가있는 UIScrollView 레이아...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
