반응형

 

 

 
 

 

 

 

 여러 오브젝트가 있을때 현재 자신이 처리할 수 있으면 처리를 하고 끝내지만 현재 자신이 처리하지 못하면

 

다음 오브젝트로 일을 보내 처리하도록 한다

 

흐름적 이점 : 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 패턴이

 

 

 

반응형

+ Recent posts