행동 관련 디자인 패턴 > 옵저버 패턴(Observer Pattern)

https://inf.run/6Shr

코딩으로 학습하는 GoF의 디자인 패턴 - 인프런 | 강의

 

 

옵저버 패턴

• 행동 관련 디자인 패턴.
• 다수의 객체가 특정 상태 변화를 감지하고 알림을 받는 패턴.
• Publish Subscribe 패턴을 구현할 수 있다.

 

 

여러 개의 객체들이 어떤 특정한 상태의 변화를 감지하고 반응해야할 때 적용할 수 있는 패턴.

이 패턴을 적용하면 pub-sub 패턴을 쉽게 구현할 수 있다.

 

주기적으로 가져오는 데 있어서 메시지가 변경되지 않았는데도 리소스가 들어가도록 구현하면 유용할까?

 

주기적으로 뭔가를 요청해서 가져오는 것을 polling이라고 하는데,

메시지가 변경되었을 때만 파악하면 되는 메커니즘에 어울리지 않는다는 것을 알 수 있다.

옵저버 디자인 패턴은 이럴 때 유용하다.

 

 

 

 

 

 

 

옵저버 디자인 패턴에서 Subject는 여러 Observer들을 등록하거나 해지하는 기능을 제공한다.

클라이언트 애플리케이션은 이러한 Subject를 사용하여 여러 Observer들을 특정 Subject에 등록하고,

또 Subject가 제공하는 특정 메서드를 사용하여 Subject의 상태를 변경할 것이다.

 

Subject에서 상태가 변경되면 자신에게 등록되어 있는 모든 Observer들을 순회하면서 Observer가 제공하는 특정 메서드들을 호출해준다.

 

Observer의 역할은 공통된 인터페이스를 제공하는 것이며, 그 인터페이스는 이벤트가 발생하였을 때 호출해줘야하는 메서드가 하나를 갖고 있다.

그 이벤트가 담고있는 정보 또는 그 이벤트 자체를 Observer에 전달하여 특정 메서드를 호출시키고 그 메서드 안에서 Observer가 해야할 일을 할 수 있게 한다.

 

Observer 인터페이스를 사용하고 있지만 Subject가 오브젝트 타입으로 갖고 있으면 인터페이스를 사용하지 않아도 된다.

하지만 그렇게 되면 어떤 메서드를 호출해야 하는지 명확하지 않아 인터페이스를 제공하는 것이 직관적이다.

 

실제로 수행하는 일은 ConcreteObserver에서 구현하면 된다.

 

Observer 디자인 패턴에서 해결하려는 문제는 어떤 특정한 객체의 상태변화를 여러 인스턴스들이 감지하고 있다가,

그 상태 변경에 반응할 수 있는 메커니즘을 제공하는 것이다.

 

 

 

 

 

 

 

 

 

 

옵저버 패턴의 장점

1. 상태를 변경하는 객체와 변경을 감지하는 객체의 관계를 느슨하게 유지할 수 있다.

2. 서브젝트의 상태 변경을 주기적으로 조회하지 않고 자동으로 감지할 수 있다.

3. 런타임에 옵저버를 추가하거나 제거할 수 있다.

 

옵저버 패턴의 단점

1. 복잡도가 증가한다.

2. 다수의 옵저버 객체를 등록 후 해지하지 않는다면 메모리릭이 발생할 수도 있다.

예시) 다른 곳에서 사용하지 않더라도 맵에 들어가 있는 이유로 가비지 컬렉터가 동작을 안 하게 된다.

 

 

 

 

 

 

 

https://refactoring.guru/ko/design-patterns/observer

Observer