여러 오브젝트가 있을때 현재 자신이 처리할 수 있으면 처리를 하고 끝내지만 현재 자신이 처리하지 못하면
다음 오브젝트로 일을 보내 처리하도록 한다
흐름적 이점 : switch 구문을 제거 할 수 있다
한 프로젝트의 도움말에 대한 사항을 분기문이 아닌 chain of responsibility 패턴으로 처리할 사항을 다음 클래스로 넘기며 처리 할 수 있는데
A, B ,C ,D, E, .... N 의 클래스가 있을때
A 에서 처리할 수 있는 도움말이면 A 에서 처리 하지만 A 에서 처리 할 수 다음 포인터 주소를 통해 다음 클래스로
처리를 넘긴다
A
success() --------------->B
success()--------------->C
success()---------------->
DNS 처리 또한 유사하게 처리 될 수 있다
단 처리 됐는지 처리 되지 않았는지 처리를 넘긴 다음에는 알지 못한다
즉 정확히 어떤 객체가 처리하는지 모른다
도움말, 프린트, 응용프로그램 등등에 대한 각 가지 다양한 종류에 대한 처리 사항을 클라이언트가 요청 할 수 있는데
그때는 요청의 종류 req->GetRequestofKind() 와 같은 종류를 구분 할 수도 있지만 좀 더 나은 방법은
Dynamic_cast 로 현재 넘어온 클래스가 어느 부류에 속하는 클래스인지 다운캐스팅 테스트를 해보아
Dynamic_cast 가 0 을 리턴하면 현재 상속구조의 클래스가 아님으로 다음 분기문에서 다시 다른 종류에 대한 클래스의 다운 캐스팅을
시도해보아 맞을때까지 분기문을 놓는 식으로 처리 한다
패턴을 오히려 너무 많이 남발하면 좋지 않다
적시 적소에 쓸 수 있어야 한다 chain of responsibility 패턴 과 쓰일 수 있는데
다음 노드로 넘어가야 하느냐 말아야 하느냐가 각 노드마다 공통인 부분이기 때문에 이 부분에 대해서 Template Method 패턴이 쓰일 수 있다
다음 으로 넘어가지 않는다고 하면 Template Method 를 지나쳐 다음을 수행 하면 되기 때문..
Template method 패턴이
'디자인패턴과방법론 > 디자인패턴' 카테고리의 다른 글
iterator 패턴, 스택제거시 삭제되는 포인터(like 스마트포인터) (0) | 2012.11.02 |
---|---|
interpreter 패턴 (0) | 2012.11.02 |
command 패턴 (0) | 2012.11.02 |
Strategy 패턴 (전략적 패턴) (0) | 2012.11.02 |
Mediator 패턴 (0) | 2012.11.02 |