답변:
Event / Listener aproach는 긴밀한 결합 을 피하려고 시도 하므로이를 나타내는 모든 코드 냄새가 접근 방식을 가리 킵니다.
이를 바탕으로 다음과 같은 증상을 제안합니다.
모든 객체는 다른 모든 객체를 알아야하며 없이는 작동 할 수 없으므로 큰 생성자 . 아마도 obj.set_dependecy(x)생성자 호출 직후에 많은 사람들이 위장했을 것 입니다.
양방향 의존성 , 이벤트없이, 명령형 언어에서 정보의 흐름은 기본적으로 '푸시'(누군가 메소드 호출)
'지식의 계층'은 결정하기 어렵다 . 이것은 양방향 의존성입니다 . 또 다른 초점입니다 .A가 있고 B를 듣는다면 A는 B를 알고 있지만 B는 A를 모르기 때문에 '계층'이 있습니다. 일부 개체는 아무것도 모르고 일부는 다른 것을 알고 있습니다 예를 들어, MVC를 다음과 같이 구현할 때 : http://en.wikipedia.org/wiki/Model_View_Controller 모델은 그 자체 만 알고 뷰는 모델을 알고 컨트롤러는 뷰와 모델을 알고 있습니다.
나는 당신의 질문을 바꾸고 말할 것입니다 : 이벤트 기반의 객체 지향 응용 프로그램에 적합한 솔루션이 아닌 경우? 대부분의 OO 응용 프로그램이 이벤트 제작자 및 소비자로 설계된 경우 이점이 있다고 생각합니다.
결국 "메소드 호출"은 실제로 객체에 도착하는 메시지이며 객체는 메시지와 관련이 있는지 여부를 결정하고 작업을 수행 할 책임이 있습니다. 이것은 Java와 같은 강력한 유형의 언어에서는 명확하지 않지만 Ruby와 같은 동적 언어에서는 더 분명해집니다.
응용 프로그램을 이벤트 기반으로 디자인하는 또 다른 흥미로운 점은 일반적으로 내부 구성 요소가 적절하게 격리되고 일관성이 있어야한다는 것입니다. 그렇지 않으면 코드가 매우 빠르게 엉망이됩니다. 예를 들어, Alistair Cockburn에서 사용하는 6 각형 아키텍처 의 개념이 정말 마음에 듭니다. 일반적으로이 패턴은 더 나은 캡슐화와 더 응집력있는 구성 요소를 만듭니다.
나는 이것이 도메인 이벤트 의 도메인 기반 설계 개념과도 관련이 있다고 생각하지만 ( 도메인 클래스는 다른 객체에 의해 캡처 된 이벤트를 생성하고, 이러한 객체는 다른 이벤트를 방출합니다. 이것은 가고있다 : D). 이 패턴에 대해 내가 좋아하는 점은 인터페이스가 구현이 아니라 역할을 모델링해야한다는 것입니다.
이해가 안된다면 죄송합니다. 지난 몇 개월 동안 놀라운 패턴으로 이러한 패턴을 실험 해 보았지만 여전히 개념과 그 범위에 대해 이해하려고 노력하고 있습니다.
이벤트 리스너 (일명 관찰자 패턴)가 존재하지 않으면 어떻게해야하는지 생각해보십시오.
다른 객체 목록을 참조하는 객체가 있고 프로세스의 특정 지점에서 해당 객체에 대한 메소드를 호출하는 경우 분명히 이벤트가 있어야합니다.
객체에 무언가가 완료되었다고 말하는 플래그가 있고 다른 객체에서 해당 플래그를보고 있다면 반드시 이벤트 중심 모델을 사용해야합니다.
그러나 이것을 콜백과 혼동하지 마십시오. 다른 객체에서 메소드를 호출하고 지정된 시간에 다시 호출 할 원래 객체의 메소드를 전달하는 경우 이벤트 리스너를 사용하지 말고 그대로 두어야합니다.