옵서버 패턴
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
옵서버 패턴은 객체의 상태 변화를 다른 객체들에게 알리는 소프트웨어 디자인 패턴이다. 이 패턴은 관찰 대상(Subject) 객체에 관찰자(Observer) 객체들을 등록하고, 관찰 대상의 상태가 변경되면 등록된 모든 관찰자에게 알림을 보낸다. 옵서버 패턴은 이벤트 기반 프로그래밍, 객체 속성 값 변화 감지, 메일링 리스트 등 다양한 상황에서 활용되며, 모델-뷰-컨트롤러(MVC) 구조에서 모델과 뷰 사이의 느슨한 연결을 구현하는 데 사용된다. 자바 Swing, C++의 Boost.Signals, Qt, C# 등 다양한 프로그래밍 언어와 라이브러리에서 구현되어 사용된다.
더 읽어볼만한 페이지
- 정보기술 용어 - 그리드 컴퓨팅
그리드 컴퓨팅은 지리적으로 분산된 컴퓨터 자원을 연결하여 가상 슈퍼컴퓨터를 구축하는 기술이며, 유휴 자원을 활용하고 과학 연구 등 다양한 분야에 활용된다. - 정보기술 용어 - 컴퓨터 클러스터
컴퓨터 클러스터는 여러 대의 상용 컴퓨터를 고속 네트워크로 연결하여 고성능 컴퓨팅 시스템을 구축하는 방식으로, 슈퍼컴퓨터를 포함한 다양한 분야에서 높은 가용성과 확장성을 제공하며, 클러스터 미들웨어를 통해 시스템 관리, 부하 분산, 통신 방식, 데이터 공유 등을 지원하고 노드 장애 관리를 위한 펜싱 기술을 활용한다. - 소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다. - 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.
| 옵서버 패턴 | |
|---|---|
| 일반 정보 | |
 | |
| 분류 | 행위 디자인 패턴 |
| 디자인 패턴 유형 | 행위 패턴 |
| 목적 | 객체 간의 일대다 의존성을 정의하여, 한 객체의 상태가 변경되면 해당 객체에 의존하는 모든 객체에게 자동으로 알리고 업데이트합니다. |
| 다른 이름 | 의존성 퍼블리시-서브스크라이브 (Publish-Subscribe) |
| 구조 | |
| 참여자 | 주체 (Subject): 옵저버 목록을 유지하고, 상태 변경 시 옵저버에게 알립니다. 옵저버 (Observer): 주체의 변경 사항에 대한 업데이트를 받기 위한 인터페이스를 정의합니다. 구체적인 주체 (ConcreteSubject): 주체 인터페이스를 구현하고, 상태를 저장하며, 상태 변경 시 옵저버에게 알립니다. 구체적인 옵저버 (ConcreteObserver): 옵저버 인터페이스를 구현하고, 주체의 상태 변경에 반응합니다. |
| 협업 | 구체적인 주체는 상태 변경 시 모든 옵저버에게 알립니다. 구체적인 옵저버는 주체로부터 업데이트를 받아 자신의 상태를 업데이트합니다. |
| 결과 | |
| 장점 | 주체와 옵저버 간의 낮은 결합도를 유지합니다. 방송 통신을 지원합니다. 예상치 못했던 업데이트를 발생시키지 않고, 애플리케이션의 다양한 부분 간에 일관성을 유지하는 간단한 업데이트 프로토콜을 만듭니다. |
| 단점 | 순환적인 업데이트에 취약합니다. 옵저버가 너무 많으면 주체의 성능에 영향을 줄 수 있습니다. 옵저버에게 전달되는 업데이트 순서가 정의되지 않았을 수 있습니다. |
| 사용 사례 | |
| 사용 예시 | 모델-뷰-컨트롤러 (MVC) 아키텍처에서 뷰는 모델의 옵저버입니다. 스프레드시트에서 셀은 다른 셀의 옵저버가 될 수 있습니다. 사용자 인터페이스 컨트롤은 기본 데이터 객체의 옵저버가 될 수 있습니다. |
| 구현 | |
| 구현 방법 | 주체는 옵저버 목록을 유지해야 합니다. 주체는 옵저버를 추가하고 제거하는 방법을 제공해야 합니다. 주체는 상태 변경 시 모든 옵저버에게 알려야 합니다. 옵저버는 주체의 상태 변경에 반응하는 방법을 정의해야 합니다. |
| 구현 시 고려 사항 | 옵저버에게 전달되는 업데이트의 순서를 정의해야 합니다. 순환적인 업데이트를 방지해야 합니다. 옵저버가 너무 많으면 주체의 성능에 영향을 줄 수 있다는 점을 고려해야 합니다. |
2. 역사
옵서버 패턴은 유연하고 재사용 가능한 객체 지향 소프트웨어를 설계하기 위해 반복적인 설계 문제를 해결하는 23가지 잘 알려진 "Gang of Four" 디자인 패턴 중 하나이다. 이는 구현, 변경, 테스트 및 재사용이 용이한 객체를 생성하는 행동 패턴이다.[1] 이 패턴은 특히 객체 간의 느슨한 결합을 유지하면서 한 객체의 상태가 변할 때 의존하는 다른 객체들에게 자동으로 알림을 보내고 업데이트할 수 있도록 하는 구조를 제공한다.
옵서버 패턴의 핵심 구조는 관찰 대상이 되는 객체('''Subject''')와 이를 지켜보는 하나 이상의 객체('''Observer''' 또는 리스너)로 이루어진다.[12] 기본적인 작동 방식은 옵서버들이 서브젝트에 자신을 등록하고, 서브젝트에서 특정 이벤트가 발생하면 등록된 모든 옵저버에게 자동으로 알림(notification)이 가는 형태이다.
3. 구조
이벤트가 발생했을 때 각 옵저버는 콜백(callback)[14]을 통해 알림을 받으며, 서브젝트는 단순히 이벤트 발생 사실 외에 추가적인 데이터를 옵저버에게 전달할 수도 있다. 옵저버는 이 알림을 받아 미리 정의된 각자의 동작을 수행한다.
이 패턴의 중요한 특징은 서브젝트와 옵저버 간의 느슨한 결합(loose coupling)이다.[2] 서브젝트는 자신을 관찰하는 옵저버들의 구체적인 클래스를 알 필요 없이, 단지 옵저버 인터페이스를 통해 상호작용한다. 마찬가지로 옵저버는 서브젝트의 내부 구현에 대해 알 필요가 없다. 이 덕분에 옵저버는 실행 중에도 동적으로 추가되거나 제거될 수 있어 시스템의 유연성과 재사용성이 높아진다. 이러한 방식은 발행-구독 모델과 유사하다.
옵서버 패턴은 객체 간의 일대다(one-to-many) 의존성을 효과적으로 관리할 수 있게 해주며, 유연하고 재사용 가능한 객체 지향 소프트웨어를 설계하기 위한 23가지 "Gang of Four" 디자인 패턴 중 하나로 널리 알려진 행동 패턴이다.[1]
3. 1. Subject (관찰 대상)
옵서버 패턴에서 '''Subject'''는 관찰 대상이 되는 객체를 의미한다. "이벤트를 발생시키는 주체"로서, 자신에게 등록된 하나 이상의 옵저버(Observer 또는 리스너)들을 관리한다.
Subject는 자신의 상태가 변하거나 특정 이벤트가 발생했을 때, 등록된 옵저버들에게 이를 알리는 역할을 한다. 이 알림 과정에서 각 옵저버는 콜백[14]을 받는다. Subject의 `notify` 함수는 이벤트 발생 사실 외에도 옵저버가 필요로 하는 추가 데이터를 인자로 전달할 수 있다.
Subject는 일반적으로 다음과 같은 메서드를 통해 옵저버를 관리하고 알림을 보낸다.
| 메서드 (예시) | 설명 |
|---|---|
| `addObserver()`, `register()` | 새로운 옵저버를 옵저버 목록에 등록한다. |
| `removeObserver()`, `unregister()` | 기존 옵저버를 목록에서 제거한다. |
| `notifyObservers()` | 목록에 있는 모든 옵저버에게 이벤트 발생을 알림한다. |
이 외에도 이벤트가 빈번하게 발생할 경우 알림이 과도하게 발생하는 것을 제어하기 위해, 일시적으로 알림을 중단하거나 재개하는 기능을 포함할 수도 있다.
옵서버 패턴을 사용하는 시스템에서는 순환 실행(cyclic execution) 문제를 주의해야 한다. 예를 들어, 이벤트 X가 발생하여 옵저버 A가 옵저버 B를 갱신하고, 이 처리 과정에서 옵저버 B가 다시 옵저버 A를 갱신하게 되면, 이는 다시 이벤트 X를 발생시키는 무한 루프에 빠질 수 있다. 이러한 상황을 방지하려면, 특정 이벤트가 한 번 처리된 후에는 동일한 이벤트가 연쇄적으로 다시 발생하지 않도록 제어하는 메커니즘이 필요하다.
Subject는 인터페이스로 정의하거나 직접 클래스로 구현할 수 있다. UML 다이어그램에서는 인터페이스와 구현 클래스를 나누어 표현하는 경우가 많지만, 이는 패턴의 필수 요건은 아니다.
3. 2. Observer (관찰자)
'''옵서버'''(Observer) 또는 '''리스너'''(Listener)는 옵서버 패턴에서 관찰 대상 객체, 즉 '''서브젝트'''(Subject)의 상태 변화를 감지하고 이에 대한 알림을 받아 처리하는 객체이다.[12] 이 패턴의 기본 원리는 하나 이상의 옵서버 객체를 서브젝트 객체에 등록하는 것이다.서브젝트에서 특정 이벤트가 발생하면, 등록된 각 옵서버는 콜백(callback)[14]을 통해 알림을 받는다. 이때 서브젝트의 `notify` 메서드는 단순히 이벤트 발생 사실뿐만 아니라, 옵서버가 필요로 하는 추가적인 인자값을 전달할 수도 있다. 통지에 사용되는 메서드는 추상 메소드로 정의되는 경우가 많으며, 언어에 따라 콜백 함수와 컨텍스트의 쌍, 함수 객체, 또는 델리게이트 등이 활용될 수 있다.[12]
각각의 구체적인 옵서버 클래스는 이 `notify` 메서드를 구현함으로써, 특정 이벤트가 발생했을 때 수행할 자신만의 동작을 정의해야 한다.
아래는 옵서버 패턴의 구조를 통합 모델링 언어 클래스 다이어그램으로 나타낸 것이다.
서브젝트는 일반적으로 옵서버를 관리하기 위한 '''등록'''(register) 및 '''제거'''(unregister) 메서드를 제공한다. 등록 메서드는 새로운 옵서버를 관리 목록에 추가하고, 제거 메서드는 기존 옵서버를 목록에서 제외한다.
옵서버 패턴을 복잡하게 사용하는 시스템에서는 순환 실행 문제를 주의해야 한다. 예를 들어, 특정 이벤트 X가 발생하여 옵서버 A가 옵서버 B를 갱신하고, 이어서 옵서버 B가 다시 옵서버 A를 갱신하게 되면 무한 루프에 빠질 수 있다. 이러한 상황을 방지하기 위해, 특정 이벤트가 한 번 처리된 후에는 동일한 이벤트를 다시 발생시키지 않도록 제어하는 메커니즘이 필요하다.
3. 3. UML 클래스 다이어그램
위 UML(통합 모델링 언어) 클래스 다이어그램은 옵서버 패턴의 구조를 시각적으로 보여준다. 이 패턴은 주로 상태 변화가 발생하는 관찰 대상 객체인 `Subject`와 이를 관찰하는 하나 이상의 `Observer` 객체들로 구성된다.
- '''`Subject`''': 상태 변화를 감지하고 이를 통지하는 주체 객체이다. 자신을 관찰하는 `Observer` 객체들의 목록을 관리하며, 새로운 옵저버를 등록(`attach` 또는 `register`)하거나 기존 옵저버를 제거(`detach` 또는 `unregister`)하는 메서드를 제공한다. 자신의 상태가 변경되면 `notify` 메서드를 호출하여 등록된 모든 옵저버에게 변경 사실을 알린다.
- '''`Observer`''': `Subject`의 상태 변화를 통지받는 객체들의 공통 인터페이스 또는 추상 클래스이다. 일반적으로 `update`라는 추상 메서드를 포함하며, `Subject`가 `notify` 메서드를 호출할 때 각 옵저버의 `update` 메서드가 실행된다.
- '''`ConcreteObserver`''': `Observer` 인터페이스를 구체적으로 구현한 클래스이다 (다이어그램의 `Observer1`, `Observer2` 등). 각 `ConcreteObserver`는 `update` 메서드 내에서 `Subject`로부터 변경된 상태 정보를 얻어오고(`getState()` 호출 등), 그에 따라 필요한 동작을 수행하거나 자신의 상태를 갱신하는 로직을 가진다.[6]
이 구조는 `Subject`가 자신을 관찰하는 구체적인 `ConcreteObserver` 클래스를 직접 알 필요 없이, 오직 `Observer` 인터페이스에만 의존하도록 만든다. 즉, `Subject`는 `Observer` 인터페이스의 `update()` 메서드 호출만으로 모든 옵저버에게 상태 변경을 전파할 수 있다. 이는 `Subject`와 `Observer` 간의 결합도를 낮추어 시스템의 유연성과 확장성을 높이는 장점을 가진다.[6]
프로그램 실행 시 상호작용은 다음과 같다. 먼저 상태 변화를 감지하려는 `ConcreteObserver` 객체들(`Observer1`, `Observer2`)이 `Subject` 객체(`Subject1`)의 `attach(this)` 메서드를 호출하여 관찰 목록에 스스로를 등록한다. 이후 `Subject1`의 상태가 변경되면, `Subject1`은 자신의 `notify()` 메서드를 호출한다. 이 `notify()` 메서드는 등록된 모든 옵저버 객체(`Observer1`, `Observer2`)의 `update()` 메서드를 순차적으로 호출한다. 마지막으로 각 옵저버는 자신의 `update()` 메서드 안에서 `Subject1`의 `getState()`와 같은 메서드를 호출하여 변경된 데이터를 확인하고, 이를 바탕으로 자신의 상태를 업데이트(동기화)한다.[6]
4. 구현
이 패턴의 핵심은 옵저버(Observer) 또는 리스너(listener)라 불리는 하나 이상의 객체를 관찰 대상이 되는 객체(Subject)에 등록시키는 것이다. 등록된 각 옵저버는 관찰 대상 객체가 발생시키는 이벤트를 받아 처리한다.
UML 다이어그램에서 볼 수 있듯, 관찰 대상 객체(Subject)는 이벤트를 발생시키는 주체이다. 이벤트가 발생하면 Subject는 등록된 모든 옵저버에게 알림을 보내며, 이는 일반적으로 옵저버의 특정 메서드(예: `update()`, `notify()`)를 호출하는 콜백(callback)[14] 방식으로 이루어진다. 이 알림에는 Subject가 발생시킨 이벤트 정보 외에 추가적인 데이터가 포함될 수도 있다. 각 옵저버는 이 알림 메서드를 구현하여 이벤트 발생 시 수행할 고유한 동작을 정의한다.
Subject는 일반적으로 옵저버를 추가하는 등록(`register` 또는 `addObserver`) 메서드와 제거하는 제거(`unregister` 또는 `removeObserver`) 메서드를 제공한다. 이를 통해 런타임에 동적으로 옵저버를 관리할 수 있다. 또한, 이벤트가 빈번하게 발생할 경우 과도한 알림을 방지하기 위해 일시적으로 알림을 중단하거나 재개하는 기능을 포함할 수도 있다.
옵서버 패턴을 구현할 때는 순환 참조로 인한 무한 루프 가능성에 유의해야 한다. 예를 들어, 이벤트 X 발생 시 옵저버 A가 옵저버 B를 갱신하고, 이 과정에서 B가 다시 A를 갱신하게 되면 동일한 이벤트가 반복적으로 처리될 수 있다. 이를 방지하기 위해 특정 이벤트가 한 번 처리된 후에는 연쇄적인 재호출을 막는 로직이 필요하다.
또한, 기본적인 옵서버 패턴 구현은 메모리 누수를 유발할 수 있으며, 이를 리스너 문제(Lapsed listener problem)라고 한다. Subject가 Observer에 대한 강한 참조를 유지하면, Observer가 더 이상 사용되지 않더라도 가비지 컬렉션 대상에서 제외될 수 있다. 이 문제를 해결하기 위해 Subject가 Observer에 대한 약한 참조(Weak Reference)를 사용하도록 구현하는 것이 권장된다.
옵서버 패턴은 유연하고 재사용 가능한 객체 지향 소프트웨어 설계를 위한 23가지 "Gang of Four" 디자인 패턴 중 하나로, 구현, 변경, 테스트, 재사용이 용이한 객체를 만드는 데 도움을 주는 행동 패턴이다.[1] 이 패턴은 주로 다음과 같은 상황에서 유용하다:[2]
- 객체 간의 일대다(one-to-many) 종속성을 객체 간 느슨한 결합(Loose Coupling)을 유지하며 정의해야 할 때.
- 하나의 객체(Subject) 상태 변경 시, 의존하는 다수의 객체(Observer)들이 자동으로 동기화되어야 할 때.
- 하나의 객체가 자신의 상태 변경을 여러 다른 객체에게 전파해야 할 때.
Subject는 Observer 목록을 관리하고 상태 변경 시 알림을 보내는 책임만 지며, Observer는 Subject에 자신을 등록/해제하고 알림 수신 시 자신의 상태를 업데이트하는 책임을 진다. 이를 통해 Subject와 Observer는 서로의 구체적인 구현에 대해 알 필요 없이 상호작용할 수 있다. 이러한 방식은 발행-구독(Publish-Subscribe) 패턴과 밀접한 관련이 있다.
OS/2나 윈도우 같은 초기 GUI 시스템에서는 '발행-구독'이나 '이벤트 기반 프로그래밍'이라는 용어가 옵서버 패턴과 유사한 의미로 사용되기도 했다.[5] 그러나 옵서버 패턴은 발행-구독 시스템의 일부 요소일 뿐이며, 메시지 큐 시스템 등 더 복잡한 발행-구독 구현에서는 옵서버 패턴 외에 메시지 전달 보장, 로깅 등 추가적인 기능들이 포함된다.[3][4]
옵서버 패턴과 관련된 다른 디자인 패턴으로는 중재자(Mediator) 패턴, 싱글톤(Singleton) 패턴 등이 있다.
4. 1. 대표적인 사례
옵서버 패턴은 다양한 상황에서 유용하게 활용된다. 대표적인 사례는 다음과 같다.- 이벤트 기반 응답: 사용자의 마우스 클릭이나 키보드 입력과 같은 외부 이벤트가 발생했을 때, 이에 대한 적절한 반응을 처리하는 데 사용된다. 예를 들어, 버튼을 클릭하면 특정 동작이 실행되도록 구현할 수 있다.
- 속성 값 변화 감지: 객체의 특정 속성 값이 변경되었을 때, 이를 감지하고 관련된 다른 객체들이 업데이트되도록 하는 데 사용된다. 예를 들어, 스프레드시트 프로그램에서 특정 셀의 값이 바뀌면, 해당 셀을 참조하는 다른 셀들의 값이나 차트가 자동으로 갱신되는 경우가 이에 해당한다. 때로는 이러한 변화가 연쇄적으로 다른 이벤트를 발생시키는 이벤트 연쇄의 원인이 되기도 한다.
- 모델-뷰-컨트롤러 (MVC) 패턴: MVC 아키텍처에서 모델(데이터)과 뷰(화면) 사이의 느슨한 결합을 구현하기 위해 자주 사용된다. 모델에서 데이터 변경이 발생하면, 모델은 자신을 관찰하고 있는 뷰(옵저버)들에게 변경 사실을 알린다. 알림을 받은 뷰는 모델로부터 최신 데이터를 가져와 화면을 갱신한다. 이를 통해 모델과 뷰는 서로 직접적으로 의존하지 않으면서도 데이터의 일관성을 유지할 수 있다.
이 패턴은 여러 프로그래밍 라이브러리와 시스템에서 널리 구현되어 있으며, 거의 모든 GUI 툴킷이 사용자 인터페이스 이벤트를 처리하기 위해 활용한다.
주목할 만한 구체적인 사용 사례는 다음과 같다.
- Java: Swing 라이브러리는 사용자 인터페이스의 이벤트 관리를 위해 옵서버 패턴을 광범위하게 사용했다. 또한, `java.util.Observer` 인터페이스와 `java.util.Observable` 클래스가 있었으나, 제한적인 구현으로 인해 Java 9부터는 사용 중단(deprecated)되었다.
- C++:
- [https://web.archive.org/web/20060219134628/http://boost.org/doc/html/signals.html Boost.Signals]: STL을 확장하여 시그널/슬롯 모델을 제공한다.
- [http://qt-project.org/doc/ QT]: 시그널/슬롯 메커니즘을 통해 옵서버 패턴을 구현한 대표적인 C++ 프레임워크이다.
- [https://web.archive.org/web/20060308173510/http://libsigc.sourceforge.net/ libsigc++]: 시그널링을 위한 C++ 템플릿 라이브러리이다.
- C#: .NET 환경에서는 `event` 키워드와 델리게이트(delegate)를 사용하여 옵서버 패턴(특히 이벤트 패턴)을 구현한다. [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/observerpattern.asp 관련 문서]에서 C#과 비주얼 베이직 닷넷을 이용한 구현 방법을 찾아볼 수 있다. `IObservable` 및 `IObserver` 인터페이스도 제공된다.
- GLib: C 언어로 객체와 시그널/콜백을 구현한 라이브러리로, 다양한 프로그래밍 언어에서 사용될 수 있도록 바인딩을 제공한다.
- 자바스크립트: 과거에는 `Object.observe` 함수를 통해 객체 변경을 감지하는 기능을 제공했으나, 현재는 사용되지 않는다.[10] 대신 명시적인 코드로 옵서버 패턴을 구현할 수 있다.[11]
5. 비판 및 한계
옵저버 패턴은 기본 구현에서 메모리 누수를 일으킬 수 있는데, 이는 리스너 문제로 알려져 있다. 이러한 문제가 발생하는 이유는 해제 패턴과 유사하게, Subject(주체)가 Observer(관찰자)에 대한 강한 참조를 유지하여 Observer가 메모리에서 해제되지 않도록 하기 때문이다. 따라서 Observer를 사용하려면 명시적으로 등록하고, 사용이 끝나면 반드시 명시적으로 등록을 해제해야 한다. 만약 Subject가 Observer에 대해 약한 참조를 사용하도록 구현한다면 이러한 메모리 누수 문제를 방지하는 데 도움이 될 수 있다.
6. 관련 패턴
참조
[1]
서적
Design Patterns: Elements of Reusable Object-Oriented Software
https://archive.org/[...]
Addison Wesley
[2]
웹인용
Observer Design Pattern
https://www.geeksfor[...]
[3]
Github
Comparison between different observer pattern implementations
https://github.com/m[...]
Moshe Bindler
2015
[4]
Safari books online
Differences between pub/sub and observer pattern
https://www.safaribo[...]
The Observer Pattern by Adi Osmani
[5]
간행물
The Windows Programming Experience
https://books.google[...]
PC Magazine
1992-11-10
[6]
웹사이트
The Observer design pattern - Structure and Collaboration
http://w3sdesign.com[...]
2017-08-12
[7]
웹사이트
IObservable Interface (System)
https://learn.micros[...]
2024-11-09
[8]
웹사이트
IObserver Interface (System)
https://learn.micros[...]
2024-11-09
[9]
웹사이트
Observer design pattern - .NET
https://learn.micros[...]
2023-05-25
[10]
웹사이트
jQuery - Listening for variable changes in JavaScript
https://stackoverflo[...]
[11]
웹사이트
Jquery - Listening for variable changes in JavaScript
https://stackoverflo[...]
[12]
Microsoft Docs
イベントのサブスクリプションとサブスクリプション解除を行う方法 - C# プログラミング ガイド | Microsoft Docs
https://docs.microso[...]
[13]
Java Bug System
"[JDK-8154801] deprecate Observer and Observable - Java Bug System"
https://bugs.openjdk[...]
[14]
문서
이것은 옵서버 클래스 내에 정의된 가상 함수이거나 함수 포인터이다. 함수 포인터는 흔히 함수 객체 또는 함수자(functor)로 불린다. 옵저버로 등록된 객체에 인자를 전달한다
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com