관찰자 디자인 패턴과“리스너”

GOF에 설명 된 Observer 디자인 패턴은 실제로 다양한 툴킷에서 발견되는 리스너와 동일한 것 같습니다. 개념들 사이에 차이점이 있습니까, 아니면 청취자와 관찰자가 실제로 같은 것입니까?

(나는 특정 컴퓨터 언어 구현을 찾고 있지 않습니다. 디자인 관점과의 차이점 (있는 경우)을 이해하고 싶습니다. 예, SOF에 대한 비슷한 질문에 대한 몇 가지 답변이 있지만 근본이 있습니다. 특정 언어에 대한 특정 질문-언어 답변이 아닌 디자인 답변을 찾고 있습니다.)

"리스너"라는 용어가 관찰자 패턴을 나타내는 지 여부는 컨텍스트에 따라 다릅니다. 예를 들어, Java Swing의 "Event Listeners"는 Observer 패턴 구현의 일부이지만 .Net "Trace Listeners"는 그렇지 않습니다.

프레임 워크 작성자가 특정 패턴 구현에 참여하는 컴포넌트에 다른 이름을 지정하는 것은 드문 일이 아니지만 일반적으로 패턴 자체를 논의 할 때 공식 패턴 이름이 사용됩니다.

디자인과 관련하여, 주어진 패턴의 구현은 종종 사용되는 언어와 플랫폼에 의해 영향을받습니다. 따라서 주어진 프레임 워크 내에서 Observer 패턴의 특정 구현 (ConcreteObserver의 역할을 설명하기 위해 "리스너"라는 용어를 사용할 수 있음)은 디자인 패턴 책에 설명 된 것과 약간 다를 수 있습니다.

Gamma et al.의 Design Patterns in Observer에 대한 설명에는 양방향성이 있습니다. 알. (GoF).

관찰자에 대한 설명에서 ConcreteObservers 중 하나가 주제에 대한 변경을 신호 할 수 있습니다. 모든 ConcreteObservers의 목록을 보유한 Subject는 해당 목록을 알립니다. 그런 다음 원동기를 포함한 모든 ConcreteObservers가 적절하게 반응합니다.

리스너의 일반적인 구현은 모두 외부의 이벤트에 반응하는 것 같습니다.

그래서 나는 리스너가 덜 일반적으로 관찰자의 경우라고 말하고 싶습니다.

리스너는 관찰자 패턴의 구현 일 수 있습니다. 리스너는 본질적으로 주어진 객체에서 이벤트가 발생하기를 기다리고 있습니다. 관찰자가하는 일입니다.

나는 당신이 언어에 대한 답변을 듣지 않았다는 것을 알고 있지만 추상적 으로이 물건에 대해 이야기하기는 어렵습니다. 따라서 .NET에서이를 조사하려면 .NET Reflector에 리스너가 포함 된 어셈블리를 열어야합니다. 그러면 어셈블리를 분해하고 디자인 패턴에 대해 논리를 확인할 수 있습니다.