때때로 이벤트를 트리거하기 전에 몇 가지 복잡한 조건을 충족해야하는 시나리오가 발생했습니다. 또한 대부분의 리스너는 추가 검사를 실행하여 작업 과정을 결정합니다. 이로 인해 작은 이벤트로 생각하고 서로를 트리거 할 수있는 더 나은 솔루션인지 생각할 수있었습니다.
연쇄 사건을 통해 나중에 추가 청중을 상당히 적은 노력으로 엮을 수있을 것입니다 (YAGNI 위반 가능 여부). 내 코드는 간단하게 이해하기 쉬운 요소로 구성되며 다른 사람들이 이해하기 어렵지 않습니다.
그러나이 솔루션의 가능한 단점은 체인에 문제가 발생하면 (예 : 사람의 실수로 인한 잘못된 이벤트 발생) 버그를 잡기가 매우 어려울 수 있습니다.
이벤트는 좋은 아이디어 체인되어 TM을 ? 그렇지 않은 경우 이벤트 관련 코드를 복잡하게 유지하는 대체 방법은 무엇입니까?
답변:
이벤트 체인은 좋은 생각입니까?
그것은 당신이 그것을 사용할 때까지 정말 좋은 생각처럼 보이는 것 중 하나입니다.
순서에 대한 암시 적 종속성없이 계단식 이벤트를 설정하는 것은 매우 어렵습니다. 무한 루프 및 때때로 메모리 누수로 인해 문제를 일으키지 않고 설정하기가 어렵습니다. 연결 위치와 계단식 위치를 모두 알아야하는 이벤트로 인해 커플 링으로 인해 클래스 설계가 더 어려워집니다.
또한 코드 디버깅 및 추론에 매우 어려움이 있습니다.
이제 때때로 그들은 코드의 구조는 이러한 문제를 제한 상대적으로 제한된 시나리오에서 사용할 수 있습니다. UI에서 계단식 이벤트를 사용하여 계층 구조를 트리거 할 수 있습니다. 계층 구조가 소유권 및 반복 문제를 제한하는 데 도움이되기 때문입니다.
여전히 요즘에는 런타임에 임의의 동작이 래치되도록하는 것보다 확장 가능한 동작에 대한 생성자의 대리자를 수락하는 것이 훨씬 더 자주 발견됩니다.
이벤트 체인은 좋은 생각입니다
시스템 구축을 시작하기 전에 솔루션을 생각하고 몇 가지 사항을 일반화하는 것이 매우 중요합니다. 예를 들어, OO 언어에서는 모든 이벤트의 기초로 기본 인터페이스 또는 추상 클래스가 있어야합니다. 이 클래스는 로깅 / 디버깅과 같은 것을 통합해야합니다. 장애를 정상적으로 처리하기 위해 일반화 된 이벤트 관리 클래스를 원할 수도 있습니다.
이벤트 체인 관련 오류를 추적하는 데 며칠을 보낸 사람의 입장에서 말하면, 이것은 매우 나쁜 생각입니다. 당신이 지적했듯이 제어 흐름을 숨기고 디버깅을 악몽으로 만들 수 있습니다. 누군가가 컨트롤을 재설정하는 오류 처리 코드를 추가했을 때 상황이 발생했습니다. 이로 인해 onPropertyChange오류 처리기가있는 컨트롤이 새로 고쳐 져서 다른 컨트롤을 다시 재설정하는 처리기 체인이 생겼습니다. 기본적으로 UI는 CPU가 100 %로 고정 된 상태로 고정됩니다.
동일한 루트 이벤트에 대해 이벤트 핸들러가 두 번 이상 트리거되지 않도록하는 방법이 있으면이를 피할 수 있지만 여러 이벤트 핸들러 호출이 필요한 상황을 상상할 수 있습니다.
다른 사람들이 언급 한 모든 이유로 이벤트 체인을 올바르게 구현하는 것은 어렵습니다.
그러나 대부분의 규칙 엔진의 기본 전제이기도합니다. JBoss Drools, IBM jRules, PegaSystems, Corticon 및 FICO Blaze Advisor는 모두 시스템에서 발생하는 이벤트를 기반으로 실행되는 규칙을 선언 할 수있는 주요 BRMS (Business Rules Management Systems)입니다. 순방향 및 역방향 체인 모두 가능하고 가능합니다.
프롤로그 언어와 그 파생어는 동일한 개념을 기반으로합니다.
관련된 알고리즘은 간단하지 않다. 디버깅은 어려울 수 있지만 모델에는 많은 가치가있다.
{A + B} > C > {D & E}내에 복잡한 솔루션을 작성하는 데 도움이되지만 이전에 언급 한 많은 사람들이 테스트와 디버깅은 여전히 고통 스럽습니다.