2

안녕하세요. Chain of Responsibility Scope이 궁금합니다.Chain of Responsibility Score

일반적으로 일반적인 패턴으로 처리기가 있으며 각 처리기는 기능 작동을 관리자에게 전달합니다. 나는 예제 시나리오에서 볼 무엇

은 다음과 같습니다 추상적으로

"Every handler has the responsibility to take an action instead and after that passing 
to supervisor. 

:

"Only one related handler is handling the functionality itself and all the other handlers 
are just passing through to their supervisor handler." 

이 같은 경우에 책임 패턴의 사슬을 위반 하는가

Chain of Responsibility Recommended Scenario: 
Handler1(Take No Action) --> Handler2 (Take No Action) --> Handler3(Take All Action) 

Chain of Responsibility Wondering Scenario: 
Handler1(Take Partial Action) --> Handler2(Take No Action) --> Handler(Take Partial Action) 

두 번째 시나리오는 책임의 사슬에 적합한가 아니면 위반하는 것인가?

예를 들어 Netty는 자체적으로 핸들러를 가지며 모든 책임있는 조치를 취하고 그들 사이에 정보도 전달합니다. Netty 핸들러 메커니즘이 책임의 사슬에 어울리다고 말할 수 있습니까?

답변

3

일반적으로 책임 맺기는 귀하가 귀하의 질문에 제시 한 권장 시나리오를 포함합니다. 즉, 주어진 'command'객체 인스턴스는 핸들러가 명령을 처리하고 완료 될 때까지 체인의 한 핸들러에서 다음 핸들러로 전달됩니다.

두 번째 시나리오 (책임 사기 시나리오)는 패턴에 심각한 합병증을 유발했기 때문에주의해야합니다. handler1은 부분적인 조치 만 취했다는 것을 어떻게 알 수 있습니까? 추가 처리기가 처리를 수행한다고 추정하면 추가 처리기를 호출하므로 아무런 필요가 없습니다. 그것은 낭비가 될 것입니다. 직면하게 될 주요 문제는 Single Responsibility Principle입니다. Handler1 예 : Handler1 & 처리기의 경우 여러 핸들러가이를 처리하기위한 명령을 찾고 있으면 명령 변경이 두 핸들러 모두에 잠재적으로 영향을 미친다는 것을 의미합니다. 이것은 내 책임이 제대로 정의되지 않을 수 있으며 또 다른 모습을 가질 자격이 있다고 나와 함께 붉은 깃발을 올릴 것입니다. 일반적으로 한 클래스의 변경으로 인해 일련의 다른 클래스를 통해 파급 효과가 발생할 수있는 상황에 대해서는 의심 스럽습니다. 이 경우 내 우선 순위는 핸들러가 아닌 클래스에 명령을 실행하는 데 필요한 코드를 추출하고 추출 된 코드를 모두 호출 할 수있는 명령을 처리 할 하나의 핸들러를 정의하는 것입니다.