옵저버 패턴편집자 확인

Subject는 상태를 가지고 있으며, 그 상태의 변화를 Observer들에게 통지하는 책임을 지닌 객체이다. 주체는 관찰자들을 등록하고 제거할 수 있는 메커니즘을 제공하며, 내부 상태가 변경될 때 등록된 모든 관찰자들에게 자동으로 알림을 보낸다. 이는 옵저버 패턴에서 정보의 근원이자 관리자의 역할을 한다.

주체는 일반적으로 다음과 같은 핵심 메서드를 포함하는 인터페이스로 정의된다.

• attach(observer): 새로운 관찰자를 목록에 등록한다.

• detach(observer): 기존 관찰자를 목록에서 제거한다.

• notify(): 등록된 모든 관찰자들에게 상태 변경을 알리기 위해 각 관찰자의 업데이트 메서드를 호출한다.

주체의 구체적인 구현체는 자신의 상태(예: 온도, 주가, 버튼 클릭 상태)를 관리한다. 상태가 변경되면 notify() 메서드를 호출하여 변경 사실을 알린다. 주체는 관찰자들이 누구인지, 어떤 구체적인 클래스인지에 대해 알 필요가 없다. 단지 Observer 인터페이스를 구현한 객체라는 사실만 알고, 그들의 update() 메서드를 호출하면 된다. 이로 인해 주체와 관찰자 사이의 결합도는 낮게 유지된다.

옵저버 패턴에서 관찰자는 주체의 상태 변화를 관찰하고 이에 반응하는 객체를 가리킨다. 관찰자는 일반적으로 인터페이스나 추상 클래스로 정의되며, 주체로부터 상태 변경 알림을 받기 위한 update 메서드(또는 유사한 이름의 메서드)를 구현해야 한다. 이 메서드는 주체가 상태를 변경했을 때 호출되는 콜백 함수의 역할을 한다.

관찰자는 구체적인 구현 클래스로 존재하며, 주체에 자신을 등록하여 관찰 대상이 된다. 등록된 관찰자는 주체의 내부 상태에 직접 접근하지 않고, 주체가 제공하는 알림을 통해서만 상태 변화를 인지한다. 이는 두 객체 간의 결합도를 낮추는 핵심 메커니즘이다. 관찰자는 필요에 따라 여러 주체에 동시에 등록될 수 있으며, 주체의 알림을 받은 후에는 자신의 로직을 수행하거나 사용자 인터페이스를 갱신하는 등의 작업을 한다.

관찰자의 주요 책임은 다음과 같이 정리할 수 있다.

이 패턴에서 관찰자는 수동적인 존재가 아니라, 자신이 관심 있는 상태 변화에 대해 능동적으로 반응하는 독립적인 구성 요소이다. 이벤트 드리븐 프로그래밍, 모델-뷰-컨트롤러 아키텍처, 분산 시스템의 이벤트 처리 등 다양한 맥락에서 이 개념이 적용된다.

옵저버 패턴의 �심은 주체(Subject)와 관찰자(Observer) 간의 느슨한 결합을 유지하면서 상태 변화를 전파하는 메커니즘이다. 이 메커니즘은 크게 등록(구독)과 알림의 두 가지 과정으로 구성된다.

등록 과정에서 관찰자는 주체에 자신을 등록하여 향후 상태 변경 알림을 받을 수 있도록 한다. 일반적으로 주체는 등록된 관찰자들의 목록(예: 리스트, 배열, 맵)을 내부적으로 유지 관리한다. 관찰자는 addObserver(), subscribe(), attach()와 같은 메서드를 호출하여 이 목록에 추가된다. 이때 주체는 구체적인 관찰자의 타입이 아닌, Observer 인터페이스에만 의존하므로 새로운 유형의 관찰자를 쉽게 추가할 수 있다.

알림 과정은 주체의 상태가 변경될 때 시작된다. 주체는 setState(), notifyObservers(), publish()와 같은 메서드를 통해 자신에게 등록된 모든 관찰자에게 변경 사실을 통보한다. 이는 등록 목록을 순회하며 각 관찰자의 업데이트 메서드(예: update(), onNotify())를 호출하는 방식으로 이루어진다. 관찰자는 이 호출을 받아 주체로부터 최신 상태 데이터를 가져오거나, 메서드 인자로 전달된 데이터를 사용하여 자신의 상태를 적절히 갱신한다.

이 메커니즘은 일대다(one-to-many) 의존성을 정의하며, 주체와 관찰자 사이의 직접적인 연결을 최소화한다. 결과적으로 주체는 관찰자들이 어떻게 반응하는지 알 필요 없이 상태 변경만 알리면 되고, 관찰자들은 필요할 때만 주체의 상태를 조회하거나 반응할 수 있다.

옵저버 패턴의 구조는 일반적으로 Subject와 Observer라는 두 가지 핵심 인터페이스 또는 추상 클래스를 중심으로 정의된다. 이 패턴의 정적인 관계는 UML 클래스 다이어그램을 통해 명확하게 표현할 수 있다.

주요 구성 요소와 그 관계는 다음과 같다.

다이어그램에서 Subject는 Observer에 대한 의존 관계(Dependency)를 가진다. 이는 Subject가 Observer 인터페이스만 알고 있으며, 구체적인 ConcreteObserver 클래스에 직접 의존하지 않음을 의미한다. ConcreteObserver는 자신이 관찰할 ConcreteSubject 객체에 대한 연관 관계(Association)를 맺어, 필요시 해당 Subject의 상태를 질의할 수 있다. 이 구조는 느슨한 결합을 실현하여, Subject와 Observer가 서로 독립적으로 변경되고 재사용될 수 있게 한다.

옵저버 패턴의 구조를 정의하는 핵심은 Subject와 Observer 인터페이스(또는 추상 클래스)이다. 이 두 인터페이스는 구체적인 구현과 무관하게 패턴의 기본 계약을 규정한다.

Subject 인터페이스는 관찰 대상 객체가 제공해야 하는 메서드를 선언한다. 일반적으로 다음과 같은 세 가지 기본 연산을 포함한다.

• attach(observer): Observer 객체를 자신의 목록에 등록(추가)하는 메서드이다.

• detach(observer): 등록된 Observer 객체를 목록에서 제거하는 메서드이다.

• notify(): 자신의 상태가 변경되었을 때 등록된 모든 Observer 객체에게 알림을 보내기 위해 호출하는 메서드이다. 이 메서드는 각 옵저버의 update() 메서드를 순차적으로 호출한다.

Observer 인터페이스는 모든 구체적인 관찰자가 구현해야 하는 업데이트 메서드를 선언한다. 이 인터페이스는 보통 단일 메서드로 구성된다.

• update(): Subject로부터 상태 변경 알림을 받았을 때 호출되는 메서드이다. 이 메서드의 시그니처는 구현 방식에 따라 다르다. 간단한 방식은 매개변수가 없는 형태로, 옵저버가 필요하면 주체에게 직접 상태를 요청하는 풀(Pull) 모델을 사용한다. 반면, 변경된 상태 정보를 매개변수로 전달받는 푸시(Push) 모델도 흔히 사용된다.

이러한 인터페이스 정의는 구체적인 ConcreteSubject와 ConcreteObserver 클래스가 이를 구현함으로써 느슨한 결합을 달성할 수 있게 한다. 주체는 옵저버의 구체적인 클래스를 알 필요 없이 오직 Observer 인터페이스 타입을 통해 통신한다.

옵저버 패턴에서 Subject에 Observer를 등록하는 과정은 관찰 관계를 설정하는 첫 번째 단계이다. 이 과정은 주체의 상태 변화를 관찰자가 수신할 수 있도록 연결 고리를 만드는 작업이다.

일반적으로 Subject 인터페이스나 클래스는 addObserver(), registerObserver(), subscribe()와 같은 이름의 메서드를 제공한다. 관찰자는 이 메서드를 호출하며, 자신의 참조(예: 객체 인스턴스)를 인자로 전달한다. 주체는 전달받은 관찰자 참조를 내부 컬렉션(예: 리스트, 배열, 맵)에 저장한다. 등록 과정 후의 관계는 다음 표와 같이 정리할 수 있다.

구현 시 고려할 점은 동일한 관찰자의 중복 등록을 방지하는 로직을 추가하는 것이다. 또한, 등록 순서에 따라 알림을 받는 순서가 결정될 수 있으므로, 이에 대한 요구사항을 명확히 하는 것이 중요하다. 등록 과정은 패턴의 동작을 시작하는 필수적인 준비 단계로, 이후 발생하는 상태 변경과 알림의 기반이 된다.

Subject (주체)의 내부 상태가 변경되면, 이는 알림 과정의 시작점이 된다. 주체는 일반적으로 자신의 상태를 변경하는 메서드(예: setState()) 내부에서 Observer (관찰자)들에게 알림을 전송하는 메서드(예: notifyObservers())를 호출한다. 이 호출은 상태 변경의 직접적인 결과로 이루어지며, 주체는 어떤 관찰자가 어떤 구체적인 변화에 관심 있는지 알 필요가 없다.

알림 메서드가 실행되면, 주체는 자신에게 등록된 모든 관찰자 객체의 목록을 순회한다. 각 관찰자에 대해 미리 약속된 인터페이스 메서드(예: update())를 호출한다. 이 메서드를 호출할 때, 주체는 필요한 경우 변경된 상태 정보를 매개변수로 전달하거나, 관찰자가 주체 객체 자신을 참조하여 필요한 정보를 다시 가져오도록 할 수 있다. 이 과정에서 주체와 관찰자는 느슨하게 결합된 상태를 유지한다.

관찰자의 update() 메서드가 호출되면, 각 관찰자는 자신의 로직에 따라 주체의 상태 변화에 대응한다. 이 대응은 화면 갱신, 데이터 기록, 다른 객체에 대한 작업 트리거 등 다양할 수 있다. 모든 등록된 관찰자에 대한 알림이 완료되면 하나의 상태 변경 주기가 종료된다.

관찰자가 더 이상 주체(Subject)의 상태 변화를 받아보지 않으려면 등록을 해지해야 합니다. 이 과정은 등록(Subscribe) 과정의 역순으로 진행됩니다. 일반적으로 Observer 인터페이스를 구현한 객체 자신을 인자로 넘겨, Subject의 등록 목록에서 자신을 제거하는 방식으로 이루어집니다.

구체적인 해지 과정은 다음과 같습니다.

1. 관찰자(예: ConcreteObserverA)는 주체 객체의 해지 메서드(예: removeObserver(), detach())를 호출합니다.

2. 호출 시, 관찰자는 자기 자신(예: this)을 메서드의 인자로 전달합니다.

3. 주체는 내부적으로 유지하는 관찰자 목록(예: List<Observer>)에서 해당 인자와 일치하는 관찰자 객체를 찾아 제거합니다.

해지가 정상적으로 완료되면, 이후 발생하는 주체의 상태 변경과 알림(Notify) 과정에서는 해당 관찰자에게 더 이상 업데이트 메시지가 전송되지 않습니다. 이 메커니즘은 메모리 누수를 방지하는 데 중요합니다. 사용이 끝난 관찰자 객체를 주체가 계속 참조하지 않도록 명시적으로 해지하는 것은 가비지 컬렉션이 정상적으로 동작하도록 보장합니다.

일부 구현에서는 관찰자가 생성되거나 등록될 때 반환되는 구독 토큰(예: Subscription 객체)을 이용해 해지하기도 합니다. 이 방식은 관찰자가 자신의 참조를 직접 노출하지 않고도 해지를 관리할 수 있게 합니다.

옵저버 패턴을 자바로 구현할 때는 일반적으로 java.util 패키지에 포함된 Observer 인터페이스와 Observable 클래스를 사용할 수 있다. 그러나 이들은 JDK 9부터 사용이 권장되지 않는다. 따라서 현대적인 자바 코드에서는 주체(Subject)와 관찰자(Observer) 인터페이스를 직접 정의하여 구현하는 방식이 더 선호된다.

다음은 직접 인터페이스를 정의한 간단한 구현 예시이다. Subject 인터페이스는 옵저버의 등록, 제거, 알림 기능을 선언하고, Observer 인터페이스는 상태 업데이트 메서드를 선언한다.

```java

// 주체(Subject) 인터페이스

interface Subject {

void registerObserver(Observer o);

void removeObserver(Observer o);

void notifyObservers();

}

// 관찰자(Observer) 인터페이스

interface Observer {

void update(String message);

}

// 구체적인 주체 클래스

class ConcreteSubject implements Subject {

private List<Observer> observers = new ArrayList<>();

private String state;

public void setState(String newState) {

this.state = newState;

notifyObservers(); // 상태 변경 시 모든 관찰자에게 알림

}

@Override

public void registerObserver(Observer o) {

observers.add(o);

}

@Override

public void removeObserver(Observer o) {

observers.remove(o);

}

@Override

public void notifyObservers() {

for (Observer observer : observers) {

observer.update(state); // 각 관찰자의 update 메서드 호출

}

}

}

// 구체적인 관찰자 클래스

class ConcreteObserver implements Observer {

private String name;

public ConcreteObserver(String name) {

this.name = name;

}

@Override

public void update(String message) {

System.out.println(name + "이(가) 메시지를 수신함: " + message);

}

}

// 사용 예시

public class ObserverPatternDemo {

public static void main(String[] args) {

ConcreteSubject subject = new ConcreteSubject();

Observer observer1 = new ConcreteObserver("옵저버1");

Observer observer2 = new ConcreteObserver("옵저버2");

subject.registerObserver(observer1);

subject.registerObserver(observer2);

subject.setState("새로운 상태 1"); // 두 옵저버 모두 알림을 받음

subject.removeObserver(observer1);

subject.setState("새로운 상태 2"); // 옵저버2만 알림을 받음

}

}

```

이 예제에서 ConcreteSubject의 setState 메서드가 호출되면 내부 상태가 변경되고, notifyObservers 메서드를 통해 등록된 모든 Observer 객체의 update 메서드가 호출된다. 실행 결과는 다음과 같다.

```

옵저버1이(가) 메시지를 수신함: 새로운 상태 1

옵저버2이(가) 메시지를 수신함: 새로운 상태 1

옵저버2이(가) 메시지를 수신함: 새로운 상태 2

```

자바 9 이상의 환경에서는 java.beans 패키지의 PropertyChangeListener와 PropertyChangeSupport를 사용하는 방법도 일반적이다. 또한, 리액티브 프로그래밍 라이브러리인 RxJava나 Project Reactor의 Observable 또는 Flux는 이 패턴을 발전시킨 형태로 볼 수 있다.

옵저버 패턴의 Python 구현은 언어의 동적 특성과 데코레이터 등의 기능을 활용하여 비교적 간결하게 표현할 수 있다. 인터페이스를 명시적으로 정의하지 않아도 덕 타이핑을 통해 동작을 구현하는 것이 일반적이다. 아래 예제는 기본적인 주체(Subject)와 관찰자(Observer) 클래스를 정의하고, 상태 변경 시 알림을 전파하는 과정을 보여준다.

```python

class Subject:

"""관찰 대상이 되는 주체 클래스"""

def __init__(self):

self._observers = []

self._state = None

def attach(self, observer):

"""관찰자를 등록한다."""

if observer not in self._observers:

self._observers.append(observer)

def detach(self, observer):

"""관찰자 등록을 해지한다."""

try:

self._observers.remove(observer)

except ValueError:

pass

def notify(self):

"""모든 등록된 관찰자에게 상태 변경을 알린다."""

for observer in self._observers:

observer.update(self)

@property

def state(self):

return self._state

@state.setter

def state(self, value):

self._state = value

self.notify() # 상태가 설정되면 자동으로 알림을 발생시킨다.

class ConcreteObserver:

"""구체적인 관찰자 클래스"""

def __init__(self, name):

self.name = name

self.observer_state = None

def update(self, subject):

"""주체로부터 알림을 받아 자신의 상태를 갱신한다."""

self.observer_state = subject.state

print(f"Observer {self.name}: 상태가 '{self.observer_state}'로 업데이트되었다.")

# 사용 예시

if __name__ == "__main__":

subject = Subject()

observer_a = ConcreteObserver("A")

observer_b = ConcreteObserver("B")

subject.attach(observer_a)

subject.attach(observer_b)

subject.state = "Ready" # 두 관찰자 모두에게 알림이 전송된다.

subject.detach(observer_b)

subject.state = "Running" # 관찰자 B는 해지되었으므로 A만 알림을 받는다.

```

보다 함수형 접근을 위해 콜백 함수를 관찰자로 직접 등록하는 방식도 자주 사용된다. 이 방식은 클래스 정의 없이 간단한 함수로 관찰자 로직을 구현할 수 있다는 장점이 있다. 또한, 파이썬의 @property 데코레이터를 활용하면 상태 변경 시점을 명확히 캡슐화하여 notify 메서드를 자동으로 호출할 수 있다.

옵저버 패턴의 주요 장점은 결합도를 낮추고 시스템의 유연성을 높이는 데 있다. 주체(Subject)와 관찰자(Observer)가 느슨하게 연결되어 있어, 서로의 내부 구현에 대해 알 필요가 없다. 이는 한 객체의 상태 변화가 여러 객체에 자동으로 통지되어야 하는 상황, 특히 일대다(one-to-many) 의존 관계를 정의할 때 매우 효과적이다.

이 패턴은 새로운 관찰자 클래스를 추가하거나 기존 관찰자를 제거하는 작업을 런타임 중에 쉽게 수행할 수 있게 한다. 주체 객체의 코드를 수정하지 않고도 새로운 유형의 관찰자를 시스템에 통합할 수 있어 개방-폐쇄 원칙을 잘 준수한다. 예를 들어, 로그를 출력하는 관찰자나 데이터베이스에 저장하는 관찰자를 기존 시스템에 추가하는 것이 간단해진다.

이러한 특성 덕분에 이벤트 드리븐 프로그래밍이나 실시간 데이터 업데이트가 필요한 사용자 인터페이스, 모니터링 시스템 등 다양한 도메인에서 널리 적용된다.

옵저버 패턴은 상태 변화를 효과적으로 전파하지만, 몇 가지 주의해야 할 단점을 가지고 있다.

첫째, 알림 순서가 보장되지 않는다. 주체(Subject)가 여러 관찰자(Observer)에게 상태 변경을 알릴 때, 등록된 순서나 특정 순서대로 알림이 전달된다는 보장이 없다. 이는 관찰자(Observer)들 간의 실행 순서에 의존적인 로직이 있을 경우 예기치 않은 동작을 초래할 수 있다. 둘째, 성능 저하의 가능성이 있다. 많은 수의 관찰자가 등록되어 있거나, 상태 변경이 빈번하게 발생하는 경우, 모든 관찰자에게 일일이 알림을 전달하는 과정이 시스템 부하를 증가시킨다. 특히 관찰자 중 하나의 처리 속도가 느리면 전체 알림 흐름이 지연될 수 있다.

셋째, 메모리 누수(Memory Leak) 위험이 존재한다. 관찰자가 더 이상 필요하지 않음에도 해지하지 않고 등록된 상태로 남아 있으면, 가비지 컬렉션(Garbage Collection)의 대상이 되지 않아 메모리가 회수되지 않을 수 있다. 이는 장시간 실행되는 애플리케이션에서 심각한 문제가 될 수 있다. 마지막으로, 디버깅이 복잡해질 수 있다. 상태 변화의 원인과 결과가 여러 객체에 분산되어 추적하기 어려우며, 알림이 연쇄적으로 발생하는 경우(예: 한 관찰자의 동작이 다시 주체의 상태를 변경함) 실행 흐름을 이해하는 데 어려움을 겪을 수 있다.

옵저버 패턴은 사용자 인터페이스 프로그래밍, 특히 이벤트 구동 프로그래밍에서 가장 널리 적용되는 패턴 중 하나이다. GUI 컴포넌트(예: 버튼, 텍스트 필드, 슬라이더)는 상태 변경(클릭, 텍스트 입력, 값 변경)이 발생하는 주체가 되고, 이러한 변경에 반응해야 하는 코드(예: 이벤트 핸들러)는 관찰자가 된다. 이 구조는 컴포넌트와 비즈니스 로직 간의 강한 결합을 제거하여 유연하고 재사용 가능한 코드를 작성할 수 있게 한다.

대부분의 현대 GUI 프레임워크는 이 패턴을 기반으로 한 이벤트 리스너 시스템을 내장하고 있다. 예를 들어, Java의 Swing이나 JavaFX, .NET의 WinForms나 WPF, 웹 프론트엔드의 JavaScript DOM 이벤트 모델이 이에 해당한다. 사용자는 버튼에 addActionListener나 addEventListener와 같은 메서드를 통해 자신의 콜백 함수를 등록하기만 하면, 나머지 알림 메커니즘은 프레임워크가 담당한다.

이 패턴의 적용 덕분에, 하나의 버튼에 여러 개의 독립적인 액션을 등록하거나, 런타임에 동적으로 리스너를 추가 및 제거하는 것이 가능해진다. 또한, GUI 컴포넌트는 자신을 누가 관찰하는지 알 필요 없이 오직 상태 변화만을 알리면 되므로, 단일 책임 원칙을 잘 준수한다. 결과적으로, UI와 애플리케이션 로직이 명확하게 분리되어 테스트와 유지보수가 용이해진다.

발행-구독 모델은 옵저버 패턴의 확장된 형태로, 발행자와 구독자 사이에 메시지 브로커 또는 이벤트 채널이 존재하는 것이 특징이다. 발행자는 특정 채널이나 토픽에 메시지를 발행하기만 하며, 실제로 어떤 구독자가 있는지 알 필요가 없다. 마찬가지로 구독자는 관심 있는 토픽을 구독하고 해당 토픽의 메시지를 수신하지만, 발행자의 정체를 알지 못한다. 이 중간 매개체는 메시지의 라우팅, 필터링, 때로는 지속성을 담당하여 발행자와 구독자 간의 결합도를 더욱 낮춘다.

옵저버 패턴이 일반적으로 단일 애플리케이션 내에서 객체 간의 직접적인 통신에 사용된다면, 발행-구독 모델은 분산 시스템에서 널리 적용된다. 예를 들어, 마이크로서비스 아키텍처에서 서비스 간의 비동기 통신, 실시간 데이터 스트리밍, 또는 로그 집계 시스템에서 이 모델을 활용한다. 대표적인 구현체로는 Apache Kafka, RabbitMQ, Redis Pub/Sub 등이 있다.

다음 표는 전통적인 옵저버 패턴과 발행-구독 모델의 주요 차이점을 보여준다.

이러한 구조 덕분에 발행-구독 모델은 시스템의 확장성과 유연성을 크게 향상시킨다. 새로운 구독자를 추가하거나 제거해도 발행자 코드를 변경할 필요가 없으며, 발행자의 부하 증가 없이 다수의 구독자를 처리할 수 있다.

MVC 아키텍처에서 옵저버 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller) 간의 느슨한 결합을 유지하는 핵심 메커니즘으로 작동한다. 모델은 애플리케이션의 데이터와 비즈니스 로직을 담당하는 주체(Subject)가 되며, 하나 이상의 뷰는 해당 데이터의 표현을 담당하는 관찰자(Observer) 역할을 한다. 모델의 상태가 변경되면 등록된 모든 뷰에게 알림을 전송하여, 뷰가 자동으로 최신 상태를 반영한 화면을 갱신하도록 한다.

이 패턴의 적용은 사용자 인터페이스와 데이터의 일관성을 보장하면서도 구성 요소들을 분리한다. 컨트롤러는 사용자 입력을 처리하고 모델을 업데이트하는 역할을 하지만, 모델이 직접 어떤 뷰를 갱신할지 알 필요는 없다. 대신 모델은 단순히 '상태가 변경되었다'는 사실만을 알리고, 각 뷰는 자신의 방식으로 이 변경에 반응한다. 이를 통해 동일한 모델에 대해 여러 개의 다른 뷰(예: 차트 뷰, 테이블 뷰)를 독립적으로 생성하고 연결하는 것이 가능해진다.

구체적인 데이터 흐름은 다음 표와 같다.

이러한 구조는 GUI 애플리케이션뿐만 아니라 웹 애플리케이션의 서버사이드 아키텍처에서도 흔히 발견된다. 예를 들어, 백엔드의 도메인 모델이 변경될 때 관련된 여러 프론트엔드 컴포넌트나 다른 서비스에 자동으로 동기화 신호를 보내는 경우에도 동일한 패턴이 적용된다. MVC에서 옵저버 패턴은 변화를 효율적으로 전파하여 애플리케이션의 유지보수성과 확장성을 높이는 데 기여한다.

옵저버 패턴과 미디에이터 패턴은 모두 객체 간의 복잡한 상호작용을 관리하는 행동 디자인 패턴이지만, 그 접근 방식과 목적에 있어 명확한 차이점이 존재합니다.

두 패턴의 핵심 차이는 객체 간의 결합 방식에 있습니다. 옵저버 패턴은 주체(Subject)와 관찰자(Observer) 사이에 일대다(one-to-many) 의존성을 정의합니다. 주체의 상태가 변경되면 등록된 모든 관찰자 객체에게 자동으로 알림이 브로드캐스트됩니다. 이는 관찰자들이 주체에 직접 연결되어 있음을 의미합니다. 반면, 미디에이터 패턴은 객체들 사이에 미디에이터(Mediator)라는 중재자를 도입하여 객체 간의 직접적인 통신을 제거합니다. 객체들은 서로를 알지 못하며, 모든 통신은 미디에이터를 통해 중개됩니다. 이는 다대다(many-to-many) 관계를 단순화하여 객체 간의 결합도를 현저히 낮춥니다.

적용 영역도 구분됩니다. 옵저버 패턴은 이벤트 드리븐 시스템, 실시간 데이터 피드, MVC 아키텍처에서 모델과 뷰를 분리하는 데 널리 사용됩니다. 미디에이터 패턴은 사용자 인터페이스에서 여러 위젯이 복잡하게 상호작용하거나, 컴포넌트 기반 시스템에서 컴포넌트들의 협력을 조정할 때 유용합니다. 요약하면, 옵저버 패턴이 '상태 변화의 전파'에 초점을 맞춘다면, 미디에이터 패턴은 '상호작용 자체의 캡슐화와 단순화'에 초점을 맞춥니다.

옵저버 패턴과 전략 패턴은 모두 객체 간의 관계를 유연하게 정의하는 행동 디자인 패턴이지만, 그 목적과 적용 방식에서 차이를 보인다. 두 패턴은 종종 함께 사용되거나, 하나의 패턴 내에서 다른 패턴의 요소를 활용하는 방식으로 연관성을 가진다.

핵심적인 연관성은 전략 패턴이 옵저버 패턴의 알림(Notify) 메커니즘을 구현하는 데 사용될 수 있다는 점이다. 옵저버 패턴에서 Subject (주체)는 상태 변경 시 등록된 모든 Observer (관찰자)에게 알림을 보낸다. 이때 각 Observer (관찰자)에게 어떤 방식으로 알릴지(예: 동기/비동기, 즉시/지연)의 전략을 전략 패턴을 통해 캡슐화하여 주입할 수 있다. 이는 Subject (주체)의 알림 로직을 변경하지 않고도 알림 방식을 유연하게 교체할 수 있게 한다.

다음 표는 두 패턴의 주요 초점과 관계를 비교한다.

또한, Observer (관찰자) 객체 자체가 특정 반응 알고리즘을 구현한 전략 패턴의 ConcreteStrategy (구체적 전략)으로 간주될 수 있다. Subject (주체)의 상태 변화에 대해 각 Observer (관찰자)가 수행하는 구체적인 업데이트 동작은 서로 다른 전략으로 볼 수 있다. 따라서 두 패턴은 상호 보완적으로 설계에 적용되어, 변화에 대한 반응이라는 큰 흐름에서 더 높은 수준의 유연성을 제공한다.