디자인 패턴 옵저버 패턴

옵저버 패턴을 이해해 봅시다.

(예시) 잡지 구독 방법
1. 잡지회사는 잡지사업을 영위하고 잡지를 발행하는 회사입니다.
2. 구독자는 특정 잡지사에 구독을 신청하고 매달 새로운 잡지가 발행될 때 잡지를 받습니다. 계속 구독하시면 매달 출판물을 받아보실 수 있습니다.
3. 구독자가 더 이상 잡지를 읽고 싶지 않을 경우 구독 취소를 신청할 수 있습니다. 이 경우 잡지는 더 이상 전송되지 않습니다.
4. 잡지사가 계속해서 광고를 하게 되면 개인 구독자와 항공업계, 호텔업계 등 다양한 업계에서 계속해서 해당 매거진을 구독하고 구독을 취소하게 됩니다.

잡지를 주체로, 구독자를 관찰자로 생각해보자.

객체 A는 주체 객체를 관찰자로 변환하도록 요청합니다. 객체 B는 관찰자 역할을 중단하도록 요청합니다. 테마 개체에 새 변수가 할당됩니다.

 

옵저버 패턴

객체의 상태가 변경되면 해당 객체에 의존하는 다른 객체에 알림이 전송되고 해당 내용이 자동으로 업데이트됩니다. 일대다 종속성으로 설정됩니다. 일대다 구조는 피험자와 관찰자로 설명됩니다. 관찰자는 대상의 상태에 따라 달라집니다. 주제 값이 변경되면 관찰자에게 즉시 알림이 전송됩니다. 귀하가 당사에 연락하는 방식에 따라 관찰자의 가치가 업데이트될 수 있습니다. 관찰자 패턴을 정의하는 방법에는 여러 가지가 있습니다. 일반적으로 주제 인터페이스와 관찰자 인터페이스를 포함하는 클래스 디자인을 기반으로 합니다

느슨한 결합

두 개체가 약하게 결합되어 있다는 것은 서로 상호 작용하지만 개체가 서로의 정보를 잘 알지 못한다는 것을 의미합니다. 관찰자 패턴은 느슨하게 연결된 주체와 관찰자로 구성된 객체 디자인을 말합니다. 주체가 관찰자의 가치를 알 수 있는 유일한 방법은 인터페이스를 구현하는 것입니다. 관찰자가 무엇을 하는지 등은 신경 쓸 필요가 없습니다. 관찰자는 언제든지 추가될 수 있습니다. 주체는 관찰자 인터페이스를 구현하는 객체에만 관심을 가지므로 매번 관찰자를 추가할 수 있습니다. 실행 중인 관찰자를 다른 관찰자로 바꿀 수 있습니다. 그럼에도 불구하고 객체는 여전히 데이터를 전송할 수 있습니다. 마찬가지로 관찰자는 언제든지 제거될 수 있습니다. 새로운 모양의 관찰자를 더 많이 만들 때 테마를 전혀 변경할 필요가 없습니다. 예를 들어 관찰자가 되어야 하는 새 클래스가 있다고 가정해 보겠습니다. 이러한 상황에서는 새로운 코스 형식을 수용하기 위해 주제를 변경할 필요가 없습니다. 여러분이 해야 할 일은 새 클래스에 관찰자의 인터페이스를 구현하고 관찰자를 등록하는 것뿐입니다. 이 질문은 전혀 고려할 필요가 없습니다. 관찰자 인터페이스를 생성할 수만 있다면 어떤 객체에도 요청할 수 있습니다. 피험자와 관찰자 모두 독립적으로 재사용할 수 있습니다. 피사체와 관찰자를 다른 목적으로 사용하고 싶어도 가능합니다. 느슨하게 결합된 관계이기 때문이다. 대상이나 관찰자가 바뀌더라도 영향을 받지 않습니다. 느슨하게 결합된 구조이기 때문에 주체나 관찰자 인터페이스를 정의하는 조건만 맞다면 어떻게 변경해도 문제가 없다. 느슨한 결합을 사용하면 발생하는 모든 수정 사항을 쉽게 처리할 수 있습니다. 유연한 구조의 시스템을 만들었기 때문입니다. 객체 간의 상호 의존성을 줄입니다.

Java 내장 옵저버 패턴의 작동 방식

Java의 내장 관찰자 패턴에는 몇 가지 차이점이 있습니다. 첫 번째는 상속입니다.
- 객체가 관찰자가 되는 방법: java.util.Observer 인터페이스를 구현합니다. 관찰 가능한 객체의 addObserver() 메서드를 실행합니다. 돈을 인출해야 하는 경우 deleteobserver() 메서드를 실행하세요.
- Observable에서 호출하는 방법: java.lang util.Observable의 슈퍼클래스를 확장하는 Observable 클래스를 정의합니다. 그런 다음 setChanged() 메서드를 호출하여 객체 상태 변경을 다른 사람과 공유합니다. 다음으로, informObservers() 또는 informObservers(Object arg) 메소드를 요청합니다.
- 관찰자가 호출되는 방법: update() 메서드가 정의되어 있지만 미묘한 차이가 있습니다. push 메소드를 사용하여 관찰자에게 데이터를 전달할 때 데이터는 데이터 객체 형태로 전달되어야 하며 informObservers(arg)에 매개변수로 전송되어야 합니다. 또는 관찰자 측에서 수신한 Observable에서 필요한 데이터를 가져오기 위해 pull 메서드를 사용하여 호출해야 합니다.
- 관찰자가 호출되는 순서에 의존하지 마십시오.

관찰자로서 귀하는 연락받는 순서에 절대 의존해서는 안 됩니다.
java.util.Observable에서 nouifyObservers() 메소드를 구현할 때 관찰자 객체에 접근하는 순서가 구현과 다르기 때문에 예상치 못한 결과가 발생할 수 있습니다. 이것이 틀렸다고 말할 수 있습니까? 아니요. 구현이 호출 순서에 따라 달라지는 경우 구현이 잘못된 것입니다. 순서에 영향을 받는 이유는 느슨하게 결합되었다고 할 수 없기 때문이다.

java.util.Observable 관련 문제

Observable은 인터페이스가 아니라 클래스입니다. 즉, 인터페이스를 구현하지 않습니다. 관찰 가능한 구현에는 재사용 및 유용성에 제한이 있습니다. 이는 Observable이 쓸모없다는 의미는 아니지만 염두에 두어야 할 몇 가지 고려 사항이 있습니다.
- Observable 클래스: 우리는 이것이 디자인 규칙에 따라 부적절하다는 것을 알고 있지만 문제가 무엇인지 살펴보겠습니다. 먼저, 관찰 가능한 클래스의 하위 클래스를 만들어야 합니다. 이미 다른 슈퍼클래스 확장을 사용하고 있는 경우 해당 클래스에 관찰 가능한 기능을 추가할 수 없습니다. 재활용이 어렵다는 뜻이다. 패턴을 사용하는 목적이 재활용이기 때문에 이는 큰 단점이 됩니다. 둘째, Observable 인터페이스가 구현되어 있지 않기 때문에 Java에 내장된 Observer API에 잘 맞는 클래스를 정의하는 것이 불가능하다. java.util 정의 수정은 허용되지 않습니다. 예를 들어 멀티스레딩은 불가능합니다. 관찰 가능한 클래스의 기본 메서드에 대한 외부 호출도 금지됩니다. Observable API를 보면 setChanged() 메소드가 protected로 정의되어 있습니다. 이 메서드는 Observable 하위 클래스에서만 사용할 수 있습니다. 즉, 개발자가 자신의 클래스를 생성하고 이를 관찰 가능한 하위 클래스 인스턴스 변수로 재활용하는 것은 불가능합니다. 또한 상속 대신 구성을 사용하는 것이 디자인 규칙을 위반한다는 사실도 보여줍니다.
- 해결책: java.util.Observable을 확장하는 경우 Observable API를 사용하는 것은 나쁜 생각이 아닙니다. 그러나 위 사항에 대해서는 직접적인 구현이 필요할 수 있습니다. 그럼에도 불구하고 Observer 패턴에 대한 정확한 이해를 바탕으로 사용한다면 어떤 API를 사용해도 잘 활용할 수 있을 것입니다.