관찰자, 발행 / 구독 및 데이터 바인딩의 차이점

관찰자 패턴 , 게시 / 구독 및 데이터 바인딩 의 차이점은 무엇입니까 ?

Stack Overflow에서 약간의 검색을 수행했지만 좋은 답변을 찾지 못했습니다.

내가 믿었던 것은 데이터 바인딩이 일반적인 용어이며 Observer 패턴 또는 Pub / Sub 패턴과 같은 다른 방법으로 구현하는 것입니다. 관찰자 패턴을 사용하면 관찰자는 관찰자를 업데이트합니다. Pub / Sub를 사용하면 0 인 게시자가 특정 클래스의 메시지를 게시 할 수 있고 0 인 가입자는 특정 클래스의 메시지를 구독 할 수 있습니다.

"데이터 바인딩"을 구현하는 다른 패턴이 있습니까?

여기에 세 가지가 있습니다.

데이터 바인딩

본질적으로 이것은 핵심에서 "개체 Y의 속성 X 값이 의미 적으로 개체 B의 속성 A 값에 바인딩 됨"을 의미합니다.

관찰자 또는 관찰 가능 / 관찰자

객체에 특정 이벤트를 알리는 기능이있는 디자인 패턴-일반적으로 실제 이벤트를 사용하여 수행됩니다. 실제 이벤트는 특정 함수 / 방법의 형태를 가진 객체의 슬롯과 유사합니다. 관찰자는 알림을 제공하는 사람이며 관찰자는 해당 알림을받습니다. .net에서 옵저버 블은 이벤트를 노출 할 수 있으며 옵저버는 "이벤트 핸들러"모양의 후크를 사용하여 해당 이벤트를 구독합니다. 통지가 발생하는 특정 메커니즘이나 관찰 할 수있는 관찰자 수에 대한 가정은 없습니다.

펍 / 서브

Observable / Observer 패턴의 다른 이름 (아마도 "브로드 캐스트"시맨틱이 있음)은 일반적으로보다 "동적"의 풍미를 의미합니다. 관찰자는 알림을 구독하거나 구독 취소 할 수 있고 하나의 관찰 가능한 대상은 여러 관찰자에게 "소리를 질 수 있습니다". .NET에서는 이벤트가 MulticastDelegate의 한 형태이므로 여러 구독자에게 이벤트 전달을 지원하고 구독 취소를 지원할 수 있으므로 표준 이벤트를 사용할 수 있습니다. Pub / Sub는 일반적으로 이벤트와 eventer 사이에 더 많은 "익명 성"을 포함하는 약간 다른 의미를 가지며, 일반적으로 모든 것을 알고있는 일부 "중간자"(메시지 큐)를 포함하는 여러 추상화에 의해 촉진 될 수 있습니다. 각 당사자는 서로에 대해 알지 못합니다.

데이터 바인딩, Redux

많은 "MVC- 유사"패턴에서, 관찰 가능은 변경된 특정 속성에 대한 정보를 포함하는 "속성 변경 알림"방식을 노출합니다. 옵저버는 암시 적이며 일반적으로 프레임 워크에 의해 생성되며 객체와 속성을 구체적으로 식별하기 위해 바인딩 구문을 통해 이러한 알림을 구독하며 "이벤트 핸들러"는 새 값을 복사하여 업데이트 또는 새로 고침 논리를 트리거 할 수 있습니다.

Redux의 데이터 바인딩

데이터 바인딩을위한 대체 구현? 자, 여기 바보 같은 것이 있습니다.

• 객체의 바운드 속성을 지속적으로 확인하는 백그라운드 스레드가 시작됩니다.
• 스레드가 마지막 확인 이후 속성 값이 변경된 것을 감지하면 값을 바인딩 된 항목으로 복사합니다.

Observer / Observable과 Publisher / Subscriber 패턴 사이에는 두 가지 주요 차이점이 있습니다.

1. 관찰자 / 관찰 가능한 패턴은 대부분 동기식 으로 구현됩니다. 즉, 관찰 가능은 일부 이벤트가 발생할 때 모든 관찰자의 적절한 메소드를 호출합니다. 출판사 / 가입자 패턴은 주로에서 구현되는 비동기 (메시지 큐를 사용하는) 방법.

2. 에서 관찰자 / 관찰 가능한 패턴의 관찰자는 관찰 알고 있습니다 . 에서, 반면 게시자 / 가입자 , 게시자와 가입자가 서로를 알 필요가 없습니다 . 그들은 단순히 메시지 큐의 도움으로 통신합니다.

올바르게 언급했듯이 데이터 바인딩은 일반적인 용어이며 Observer / Observable 또는 Publisher / Subscriber 메소드를 사용하여 구현할 수 있습니다. 데이터는 게시자 / 구독자입니다.

나는 여기에있는 모든 대답이 구체적인 예를 제시하지 않고 관찰자와 펍 / 서브 패턴의 미묘한 차이점을 설명하려고 노력하고 있음을 약간 즐겁게 생각합니다. 나는 대부분의 독자들이 여전히 하나는 동기식이고 다른 하나는 비동기식으로 읽음으로써 각각을 구현하는 방법을 모른다고 확신합니다.

한 가지주의해야 할 점은 이 패턴의 목표는 코드를 분리하는 것입니다.

옵저버는 객체 (주체라고 함)가 객체 (관찰자)에 따라 객체 목록을 유지하고 상태 변경 사항을 자동으로 알려주는 디자인 패턴입니다.

관찰자 패턴

이것은 observable object모든 것을 유지하는 목록 이 있음을 의미합니다.observers (보통 기능인) . 이 목록을 탐색하고 좋은 시간이되면이 함수를 호출 할 수 있습니다.

이 관찰자 패턴을 참조하십시오 예제를 참조하십시오.

이 패턴은 오브젝트에서 데이터 변경 사항을 청취하고 다른 UI보기를 적절하게 업데이트하려는 경우에 좋습니다.

그러나 Cons are Observables 는 관찰자를 유지하기 위해 하나의 배열 만 유지 합니다 (예에서 배열은observersList ).

업데이트가 하나만 있기 때문에 업데이트가 트리거되는 방식을 구별하지 않으며 notify function, 해당 배열에 저장된 모든 기능을 트리거합니다.

다른 이벤트를 기반으로 옵저버 핸들러를 그룹화하려는 경우. 우리는 그것을 좋아 observersList하는 것으로 수정해야 합니다.Object

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

자세한 내용은 이 pubsub 예 를 참조하십시오.

사람들은이 변형을이라고 pub/sub합니다. 따라서 events게시 한 내용 에 따라 다른 기능을 트리거 할 수 있습니다 .

그럼에도 불구하고 나는 두 가지 패턴에 대한 결론에 동의하지만, 나는 같은 프로세스에있을 때 Observable을 사용하고 프로세스 간 시나리오에서 Pub / Sub를 사용합니다. 모든 당사자는 공통 채널 만 알고 있지만 당사자는 아닙니다. .

다른 패턴을 모르거나 이런 식으로 말하면이 작업에 다른 패턴이 필요하지 않았습니다. 대부분의 MVC 프레임 워크 및 데이터 바인딩 구현에서도 내부적으로 관찰자 개념을 사용합니다.

프로세스 간 통신에 관심이 있다면 다음을 권장합니다.

"엔터프라이즈 통합 패턴 : 설계, 구축 및 배포 메시징 솔루션" - http://www.addison-wesley.de/9780321200686.html

이 책에는 프로세스 내 통신 작업에서도 사용할 수있는 프로세스 또는 클래스간에 메시지를 보내는 방법에 대한 많은 아이디어가 포함되어 있습니다 (더 느슨하게 프로그래밍하는 데 도움이 됨).

이게 도움이 되길 바란다!