관찰자 패턴과 이벤트 기반 접근 방식의 차이점
나는 항상 관찰자 패턴이 일반적인 이벤트 중심 접근 방식과 거의 비슷하다는 것을 발견했습니다. 사실, 나는 그들이 실제로 같은 것을 가리키는 다른 이름이라고 거의 믿었습니다. 둘 다 유사한 개념을 사용하여 무언가를 리스너로 사용하고 구현에서도 거의 동일합니다. 즉, 액션을 수행하는 콜백 메서드 / 함수를 갖는 것입니다. 이것은 적어도 Java입니다.
다른 언어에서는 Actionscript / Flex라고 말하며 이벤트가 더 사용자 친화적이며 관찰자 패턴이 정의하는 것 이상을 수행하는 것처럼 보일 수 있습니다. 그러나 여전히 개념은 동일하게 들립니다.
그러나 이것이 정말로 사실입니까? 관찰자 패턴이 일반적인 이벤트 중심 프로그래밍 스타일과 동일한가요?
관찰자 패턴은 매우 특별한 경우입니다. 이벤트 기반은 무엇이든 의미 할 수 있습니다. 대부분의 Observer 패턴 구현에서 Observer는 관찰자를 감시하는 객체입니다. 관찰자가 변경되면 관찰자의 메서드가 호출됩니다. 엄밀히 말하면 이것은 "이벤트"가 아닙니다. 즉, 관찰자에 대한 다양한 다른 작업이 일반적으로 다른 메서드 호출로 이어 집니다.관찰자에서. "무엇"이 변경된 의미는 메서드에 있습니다. 이벤트 기반 시스템에서는 기본적으로 하나의 소비 객체 / 메서드와 변경된 내용 또는 발생한 내용이 이벤트에 있습니다. 그것은 무엇이든 될 수 있으며 무언가를 관찰한다는 아이디어에 국한되지 않습니다! 즉, 이벤트 기반 시스템에서 새로운 이벤트 유형을 추가하여 새로운 의미를 얻습니다. Observer 패턴에서는 일반적으로 Observer 클래스에 메서드를 추가하여 의미를 추가합니다. 그러나 아무도 당신이 Observer를 ChangeEvents에 대한 특별한 listern으로 구현하는 것을 방해하지 않습니다.
게시자 또는 주제에 상태가 변경되면
이벤트 기반 아키텍처 (메시지 기반 아키텍처) 는 메시지를 구독자에게 비동기 적 으로 전달하는 역할을 합니다 .
관찰자 패턴 (소프트웨어 디자인 패턴)은 구독자에게 동 기적으로 무언가를 하도록 명령 하는 역할을 합니다.
이벤트 중심 프로그래밍 은 패러다임을 정의하는 용어입니다. 반면, 관찰 가능한 패턴 응용 프로그램은 이벤트 구동 할 수있는 디자인 솔루션입니다.
건배!
차이점 1은 Event-Systems가 관찰자로부터 관찰 대상을 분리하는 eventdispatchthread를 항상 가지고있어 이벤트가 관찰자에게 즉시 도달하지 않을 수 있다는 것입니다. 실제 옵저버 블은 옵저버 메소드를 직접 호출하지만 이벤트 기반 옵저버 블은 이벤트를 이벤트 큐에 드롭합니다. 그런 다음 EDT는 이러한 이벤트를 등록 된 리스너에 전달합니다.
이 질문,이 hackernoon 기사 및 내 경험에 대한 여러 답변을 종합 하면 Observer Pattern과 Event-Driven (Pub-Sub, 예를 들어) 아키텍처의 주요 차이점은 다음과 같습니다.
옵저버 패턴에서 Observ의 에드 의 Observ에 대한 참조 유지 ERS를 .
Pub-Sub에서 브로드 캐스터는 리스너가 누구인지 알지 못합니다. (또는 누군가가들을 수 있더라도) 리스너는 브로드 캐스터로부터 일부 데이터를 기대할 수 있지만 이벤트가 어디에서 오는지 정확히 알지 못합니다. 여러 클래스 또는 원격 시스템에서 올 수 있습니다. 아마. 브로드 캐스터 나 리스너 모두에게 중요하지 않습니다.
자, 이것들이 매우 다르다는 것은 아닙니다. 또한 둘 중 하나 또는 둘 다처럼 작동하는 구현이 있습니다.
예를 들어, wisper rubygem을 사용하면 필요에 따라 Observer 패턴이나 Pub-Sub 패턴처럼 행동 할 수 있습니다. 원한다면 둘 다 함께 사용할 수도 있습니다.
나는이 같은 질문에 대해 조금 검색했습니다. 이 스레드의 경우 Angel O'Sphere의 "What semantics"에 대한 포인트와 Spacerat의 "Dispatcher"에 대한 포인트가 도움이됩니다.
그 두 가지 점은 Even-Driver와 Observer Pattern을 구별하는 내 이해입니다. 적어도 정식 설명에서 "Observer Pattern"은 일반적으로 "Subject"가 변경되고 "Dispatching"이 가입자 또는 청취자가 제공하는 인터페이스를 호출하여 구현되면 즉시 방송을 나타냅니다. 이벤트 기반의 경우 항상 "Subject"와 "Observer"사이에 또 다른 계층이 있습니다. "Dispatcher"라고 부르거나 "Event Queue"를 사용합니다. 이것은 CPU 사용량을 줄이기 위해 "지연된"처리를 제공하고 다른 호출에 대한 특정 기능을 제공합니다. 인터페이스는 다른 이벤트 유형에 따라 다릅니다.
둘 다의 기본적인 차이점은 결합과 동기 동작입니다. 관찰자 패턴을 고수하면 신호 소스가 하나 뿐이고 동기식이라고 말하고 다른 한편 이벤트와 함께 두 당사자를 분리하여 독립적으로 작업하고 동시에 둘 이상의 소스를 가질 가능성을 즐깁니다. 코드 변경없이 향후 이벤트. 이벤트는 비동기를 디자인으로 수용하는 데 도움이됩니다. 모든 Reactive 프로그래밍 라이브러리는 이벤트 기반 설계를 매우 잘 지원합니다.
한 번도 도움이 되었기 때문에 매우 간단하게 시도합니다.
Observer와 Observable로 생각하십시오. 옵저버 블이 setChanged를 표시하고 옵저버가 옵저버 블에서 변경된 사항을 요청하는 대신 옵저버 블은 변경 사항에 대한 모든 관련 정보가 포함 된 객체 (Event Carried State)를 옵저버에게 브로드 캐스트합니다. 따라서 실제로 Observer와 Observable 사이에 인스턴스가 하나 더 있습니다.
http://www.grahambrooks.com/event-driven-architecture/patterns/stateful-event-pattern/
예, 거의 동일합니다.
이벤트는 일부 언어에 대한 "내장"관찰자 패턴 템플릿과 같습니다.
따라서 이벤트가 이미 원하는 것을 제공하므로 이벤트를 지원하는 언어로 관찰자 패턴을 실제로 구현하지 않을 것입니다.
반면에 옵저버 패턴을 사용하여 이벤트가없는 언어로 이벤트 기반을 작성할 수 있습니다.
에서 위키 백과 :
관찰자 패턴은 주체라고하는 객체가 관찰자라고하는 종속 항목 목록을 유지하고 일반적으로 메서드 중 하나를 호출하여 상태 변경을 자동으로 알리는 소프트웨어 디자인 패턴입니다.
주로 "이벤트 구동"소프트웨어에서 분산 이벤트 처리 시스템을 구현하는 데 사용됩니다. Java 및 C #과 같은 대부분의 최신 언어에는 쉬운 프로그래밍과 짧은 코드를 위해 관찰자 패턴 구성 요소를 구현하는 "이벤트"구조가 내장되어 있습니다.
관찰자 패턴 은 좀 더 추상적이고 이론적입니다. 이벤트는 하나의 (일반적으로 내장 된) 구현 이지만 Angel의 답변에서 언급했듯이 이벤트는 관찰자 패턴에서 엄격하게 정의 된 것과는 다른 몇 가지 다른 상황에서 사용할 수있는 경향이 있습니다.
'programing tip' 카테고리의 다른 글
| jsdoc로 익명 객체와 함수를 문서화하는 가장 좋은 방법 (0) | 2020.12.05 |
|---|---|
| 자바에서 c 함수 호출 (0) | 2020.12.05 |
| 게으른 평가 특성 설명 (0) | 2020.12.05 |
| Jupyter / IPython 입력 프롬프트 번호를 재설정하려면 어떻게해야합니까? (0) | 2020.12.05 |
| Swift의 원시 값에서 열거 형을 얻는 방법은 무엇입니까? (0) | 2020.12.04 |