2014-05-22 7 views
6

나는 얼마전에 Chain of Responsibility를 찾고 있었는데, this 예제를 보았습니다.Chain of Responance 디자인 패턴과 간단한 if-elseif-else 블록의 차이점은 무엇입니까?

기본적으로 추상 핸들러가 있으며 구체적인 핸들러는 각각 부모 추상 핸들러의 handle 메소드를 구현합니다. 구현은 처음에는이 특정 처리기가 현재 요청을 처리 할 수 ​​있는지 확인하기위한 검사가 있으며, 그렇지 않으면 요청을 후속 장치로 전달합니다.

이제 간단한 if-else 조건부 블록을 사용하여 동일한 작업을 수행 할 수도 있습니다. 여기에, 위의 링크에서 첫 번째 예제를 이용하려면 내가 그것을 바꿀 것 방법입니다

class SingleHandler 
{ 
    if(request > 0 && request <= 10) 
    { 
     // Process request 
    } 
    else if(request > 10 && request <= 20) 
    { 
     // Process request differently 
    } 
    else if(request > 20 && request <= 30) 
    { 
     // Process request differently 
    } 
} 

자, 내 질문은, 둘 사이의 근본적인 차이는 무엇인가? if-else 블록을 사용하여 똑같은 기능을 제공 할 수 있다면 책임의 한계를 사용해야하는 특정 이유가 있습니까? 성능, 메모리 소비, 유지 보수성, 확장 성 측면에서 어느 것이 더 낫습니까?

답변

14

예,이 예제를 다시 작성하여 여러 개의 if-else-cascades를 사용할 수 있습니다. 그러나 이것은 단지 간단한 예일뿐입니다.

책임 사슬은 동적 패턴입니다. 즉, 런타임 중에 핸들러를 교환 할 수 있습니다. 이것은 여러 개의 중첩 컨트롤이 핸들러를 나타낼 수있는 UI 코드에서 종종 수행됩니다. 다음과 같은 시나리오를 상상해보십시오 :

창이 있습니다. 이 창에는 일종의 패널이 있습니다. 이 패널에는 텍스트 상자가 있습니다. 텍스트 상자를 마우스 오른쪽 단추로 클릭합니다. 실행 된 명령은 계층 구조에 따라 다릅니다. 시스템은 첫 번째 처리기 (텍스트 상자)에 클릭 요청을 처리하도록 요청합니다. 요청에 대한 처리 방법을 모르는 경우 부모 - 패널 등으로 전달합니다.이 시나리오를 if-else-cascade와 함께 구현하려는 것은 의심 스럽습니다. UI를 변경할 때마다 캐스케이드를 변경해야합니다. 그것이 핸들러 객체가 사용되는 이유입니다. 그것은 코드를 교환하고 재사용 가능하게 만듭니다.

많은 패턴이 다른 방식으로 구현 될 수 있습니다. 이는 객체 지향이없는 저수준 프로그래밍 언어에서 통상적 인 방법입니다. 그러나 이러한 코드는 일반적으로 매우 융통성이없고 유지하기가 어렵습니다. 그러나 이것이 바로 그들을 빨리 만드는 것입니다.