🎨 02. 옵저버 패턴

⛈️ 기상 모니터링 애플리케이션 알아보기

Weather-O-Rama의 차세대 인터넷 기반 기상 스테이션 구축 프로젝트에 함께하게 되었다. 기상 모니터링 애플리케이션은 총 3가지 요소로 이루어진다.

• 기상 스테이션 (실제 기상 정보를 수집하는 물리 장비)
• WeatherData 객체 (기상 스테이션으로부터 오는 정보를 추적하는 객체)
• 사용자에게 현재 기상 조건을 보여 주는 디스플레이 장비

요구사항은 WeatherData 객체로 현재 조건, 기상 통계, 기상 예보 3가지 항목을 디스플레이 장비에서 갱신해 가면서 보여 주는 애플리케이션을 만들어야 한다.

⛈️ WeatherData 클래스 살펴보기

// WeatherData

// 하기 3가지 메소드는 온도, 습도, 기압 값을 리턴하는 메소드이다.
getTemperature()
getHumidity()
getPressure()

// 기상 관측값이 갱신될 때마다 이 메소드가 호출된다.
measurementsChanged()

현재 조건, 기상 통계, 기상 예보를 보여 주는 3가지 디스플레이가 업데이트 되도록 measurementsChanged()를 바꿔보자.

⛈️ 구현 목표

measurementsChanged() 메소드가 호출될 때마다 WeatherData()에서 디스플레이를 업데이트해야 한다는 사실까지는 파악했다. 그러려면 어떻게 해야 할까?

• WeatherData() 클래스에는 3가지 측정값(온도, 습도, 기압)의 게터 메소드가 있다.
• 새로운 기상 측정 데이터가 들어올 때마다 measurementsChanged() 메소드가 호출된다.
• 기상 데이터를 사용하는 디스플레이 요소 3가지를 구현해야 한다.
  • 현재 조건, 기상 통계, 기상 예보
• 디스플레이를 업데이트하도록 measurementsChanged() 메소드에 코드를 추가해야 한다.

추가 목표

나중에 기상 스테이션이 성공하면 디스플레이가 더 늘어날 수도 있고, 디스플레이를 추가할 수 있는 마켓플레이스가 만들어질 수도 있다. 확장 기능을 추가해 보자.

• 확장성: 사용자가 마음대로 디스플레이 요소를 더하거나 뺄 수 있도록 한다.

---

⛈️ 기상 스테이션용 코드 추가하기

우선 measurementsChanged() 메소드에 다음과 같이 코드를 추가하였다.

public class WeatherData{

		// 인스턴스 변수 선언
    
    public void measurementsChanged(){
	    	// WeatherData에 있는 게터 메소드를 호출해서 최신 측정값을 가져온다.
	      // 각 값을 적당한 변수에 저장한다.
	    	float temp = getTemperature();
        float humidity = getHumidity();
        float pressure = getPressure();

        // 각 디스플레이를 갱신한다.
        // 최신 측정값을 전달하면서 각 디스플레이 항목의 update 메소드를 호출한다.
        currentConditionsDisplay.update(temp, humidity, pressure);
        statisticsDisplay.update(temp, humidity, pressure);
        forecastDisplay.update(temp, humidity, pressure);
    }

    // 기타 메소드
}

⛈️ 원칙으로 추가 코드 살펴보기

currentConditionsDisplay.update(temp, humidity, pressure);
statisticsDisplay.update(temp, humidity, pressure);
forecastDisplay.update(temp, humidity, pressure);

해당 코드의 특징은 다음과 같다.

• 인터페이스가 아닌 구체적인 구현을 바탕으로 코딩하고 있다.
  • 구체적인 구현에 맞춰서 코딩했으므로 프로그램을 고치지 않고는 다른 디스플레이 항목을 추가하거나 제거할 수 없다.
• 새로운 디스플레이 항목이 추가될 때마다 코드를 변경해야 한다.
• 실행 중에 디스플레이 항목을 추가하거나 제거할 수 없다.
• 바뀌는 부분을 캡슐화하지 않았다.
  • 상기 부분은 바뀔 수 있는 부분으로 캡슐화해야 한다.
• 모두 온도, 습도, 기압 값을 받아들이는 update() 메소드를 가지고 있다.

---

⛈️ 옵저버 패턴 이해하기

신문이나 잡지를 구독하는 메커니즘에 대해 생각해 보자.

• 신문사가 사업을 시작하고 신문을 찍어낸다.
• 독자가 특정 신문사에 구독 신청을 하면 매번 새로운 신문이 나올 때마다 배달을 받을 수 있다. 구독을 해지하기 전까진 신문을 계속 받을 수 있다.
• 신문을 더 이상 보고 싶지 않으면 구독 해지 신청을 한다. 그러면 더이상 신문이 오지 않는다.
• 신문사가 망하지 않는 이상 개인, 호텔, 항공사 및 기타 회사 등은 꾸준하게 신문을 구독하거나 해지한다.

신문사 + 구독자 = 옵저버 패턴

신문사를 주제(subject), 구독자를 옵저버(observer)라고 부른다고 생각하면 된다.

⛈️ 옵저버 패턴의 작동 원리

• 오리 객체가 등장해서 주제한테 자기도 옵저버가 되고 싶다고 이야기 한다.
  • 주제에서 상태가 바뀔 때마다 보내 주는 int 값에 정말 관심이 많았던 오리는 정말로 옵저버가 되고 싶다.
• 오리 객체도 정식 옵저버가 된다.
  • 오리는 구독자 목록에 이름을 올리고 다음에 전달될 int 값을 애타게 기다린다.
• 주제 값이 바뀌었다.
  • 오리를 비롯한 모든 옵저버가 주제 값이 바뀌었다는 연락을 받는다.
• 쥐 객체가 옵저버 목록에서 탈퇴하고 싶다는 요청을 한다.
  • 쥐 객체는 한참 전부터 int 값을 받아왔지만 지겨워서 해지 요청을 한다.
• 주제가 요청을 받아들여 쥐 객체를 옵저버 집합에서 제거한다.
• 주제에 새로운 int 값이 들어온다.
  • 모든 옵저버가 값이 바뀌었다는 연락을 받는다. 쥐는 이제 연락을 받을 수 없으므로 새로은 int 값이 무엇인지 알 수 없고, 알고 싶다면 다시 옵저버 등록 요청을 하면 된다.

⛈️ 옵저버 패턴의 정의

옵저버 패턴(Observer Pattern) 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의한다. 옵저버 패턴은 보통 주제 인터페이스와 옵저버 인터페이스가 들어있는 클래스 디자인으로 구현한다.

⛈️ 느슨한 결합의 위력

느슨한 결합(Loose Coupling)은 객체들이 상호작용 할 수는 있지만, 서로를 잘 모르는 관계를 의미한다. 느슨한 결합을 활용하면 유연성이 아주 좋아지는데, 옵저버 패턴은 느슨한 결합을 보여주는 훌륭한 예다.

• 주제는 옵저버가 특정 인터페이스(Observer 인터페이스)를 구현한다는 사실만 안다.
  • 옵저버의 구상 클래스가 무엇인지, 옵저버가 무엇을 하는지는 알 필요 없다.
• 옵저버는 언제든지 새로 추가할 수 있다.
  • 주제는 Observer 인터페이스를 구현하는 객체의 목록에만 의존하므로 언제든지 새로운 옵저버를 추가할 수 있다.
  • 실행 중 하나의 옵저버를 다른 옵저버로 바꿔도 주제는 계속해서 다른 옵저버에 데이터를 보낼 수 있다.
  • 마찬가지로 아무 때나 옵저버를 제거해도 된다.
• 새로운 형식의 옵저버를 추가할 때도 주제를 변경할 필요가 전혀 없다.
  • 옵저버가 되어야 하는 새로운 구상 클래스가 생긴 경우, 주제를 바꿀 필요 없이 새로운 클래스에서 Observer 인터페이스를 구현하고 옵저버로 등록하면 되므로 주제는 신경 쓸 필요가 없다.
• 주제와 옵저버는 서로 독립적으로 재사용할 수 있다.
  • 서로 단단하게 결합되어 있지 않기 때문이다.
• 주제나 옵저버가 달라져도 서로에게 영향을 미치지 않는다.

디자인 원칙

상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.

• 느슨하게 결합하는 디자인을 사용하면 변경사항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있다. 객체 사이의 상호의존성을 최소화할 수 있기 때문이다.

⛈️ 기상 스테이션 설계하기

• Subject
• Observer
  • 모든 기상 구성 요소에 Observer 인터페이스를 구현
  • 주제에서 옵저버에 갱신된 정보를 전달하는 방법을 제공
• DisplayElement
  • 모든 디스플레이 요소에 구현 인터페이스를 하나 더 만듦
• WeatherData
  • Subject 인터페이스를 구현
• CurrentConditionsDisplay
  • WeatherData 객체로부터 얻은 현재 측정값을 보여줌
• StatisticsDisplay
  • 측정치의 최솟값, 평균, 최댓값을 추적하고 화면에 표시함
• ForecastDisplay
  • 측정치를 바탕으로 기상 예보를 화면에 표시함
• ThirdPartyDisplay
  • 다른 개발자들도 Observer와 DisplayElement 인터페이스를 구현해서 새로운 디스플레이 요소를 만들 수 있음

⛈️ 기상 스테이션 구현하기

pubilc interface Subject{
	// Observer를 인자로 받아 각각 옵저버를 등록하거나 제거
	public void registerObserver(Observer o); 
  public void removeObserver(Observer o);
    
  // 주제의 상태가 변경되었을 때 모든 옵저버에게 변경 내용을 알림
  public void notifyObservers();
}

// 모든 옵저버 클래스에서 구현해야 함
// 따라서 모든 옵저버는 update() 메소드를 구현해야 함
public interface Observer{
	public void update(float temp, float humidity, float pressure);
}

// 디스플레이 항목을 화면에 표시해야 할 때 메소드를 호출함
public interface DisplayElement{
	public void display();
}

⛈️ Subject 인터페이스 구현하기

public class WeatherData implements Subject {
// WeahterData에서 Subject 인터페이스 구현
	private List<Observer> observers; // Observer 객체를 저장하는 ArrayList 추가
	private float temperature;
	private float humidity;
	private float pressure;
	
	public WeatherData() {
		observers = new ArrayList<Observer>(); // 생성자가 객체 생성
	}
	
  // 옵저버가 등록을 요청하면 목록 맨 뒤에 추가
	public void registerObserver(Observer o) {
		observers.add(o);
	}
	
  // 옵저버가 탈퇴를 요청하면 목록에서 뺌
	public void removeObserver(Observer o) {
		observers.remove(o);
	}
	
  // 모든 옵저버에게 상태 변화를 알림
  // 모두 Observer 인터페이스를 구현하는 update() 메소드가 있는 객체들이므로 손쉽게 상태 변화를 알려줄 수 있음
	public void notifyObservers() {
		for (Observer observer : observers) {
			observer.update(temperature, humidity, pressure);
		}
	}
	// 여기까지 Subject 인터페이스를 구현 부분
	
  // 기상 스테이션으로부터 갱신된 측정값을 받으면 옵저버들에게 알림
	public void measurementsChanged() {
		notifyObservers();
	}
	
	public void setMeasurements(float temperature, float humidity, float pressure) {
		this.temperature = temperature;
		this.humidity = humidity;
		this.pressure = pressure;
		
		// 실제 장비에서 기상 데이터를 가져오는 대신 메소드를 활용해 디스플레이 항목을 테스트
		measurementsChanged();
	}

	// 기타 WeatherData 메소드

}

⛈️ 디스플레이 요소 구현하기

// API 구조상 모든 디스플레이 항목에서 DisplayElement 구현하기로 했으므로 구현함
// WeatherData 객체로부터 변경 사항을 받으려면 Observer를 구현해야 함
public class CurrentConditionsDisplay implements Observer, DisplayElement {
	private float temperature;
	private float humidity;
	private WeatherData weatherData;
	
  // 생성자에 weatherData라는 주제가 전달되며, 그 객체를 써서 디스플레이를 옵저버로 등록
	public CurrentConditionsDisplay(WeatherData weatherData) {
		this.weatherData = weatherData;
		weatherData.registerObserver(this);
	}
	
  // update()가 호출되면 온도와 습도를 저장하고 display()를 호출
	public void update(float temperature, float humidity, float pressure) {
		this.temperature = temperature;
		this.humidity = humidity;
		display();
	}
	
  // 가장 최근에 받은 온도와 습도를 출력
	public void display() {
		System.out.println("Current conditions: " + temperature 
			+ "F degrees and " + humidity + "% humidity");
	}
}

⛈️ 푸시와 풀 방식

옵저버 패턴에서 구독자(Observer)가 변화하는 데이터를 받아오는 방식은 크게 푸시(Push) 방식과 풀(Pull) 방식으로 나뉜다.

✅ 1. 푸시(Push) 방식: “데이터를 바로 보내줌”

주제(subject)가 변경된 데이터를 옵저버(Observer)에게 자동으로 전달하는 방식.

• 옵저버가 원하는 정보만 선택할 수 없음: 주제가 주는 대로 받아야 함

📢 뉴스 알림(Push Notification)

- 뉴스 앱에서 "속보 알림"을 보내면, 내가 원하든 원하지 않든 바로 받아야 함. - `useEffect()`에서 **의존성 배열이 변경될 때마다 자동으로 실행**되는 것과 비슷함.

useEffect(() => {
  console.log("상태가 변경되었습니다:", count);
}, [count]); // count 값이 변경되면 자동 실행 (Push 방식)

📌 장점

✅ 실시간으로 데이터가 전달되므로 반응성이 좋음.

📌 단점

❌ 불필요한 데이터까지 받을 수 있어 비효율적일 수 있음.

---

✅ 2. 풀(Pull) 방식: “필요할 때 가져감” !MEMO : 느슨한 결합은 아님

👉 옵저버(Observer)가 필요할 때만 주제(subject)에게 데이터를 요청하는 방식.

• 구독자가 원할 때만 최신 데이터를 가져올 수 있음.

🍜 라면 끓이기 (Pull 방식)

- 배고플 때 내가 냄비를 열어보고 "다 됐나?" 확인하고 먹음.
- 라면이 "다 익었어요!"라고 말해주지는 않음. - `useStore.getState()`처럼 **필요할 때 직접 가져오는 방식**

const count = useStore.getState().count; // 현재 count 값을 직접 가져옴 (Pull 방식)
console.log("현재 카운트 값:", count);

📌 장점

✅ 불필요한 업데이트가 적어 성능이 좋음.

📌 단점

❌ 실시간 업데이트가 필요할 때는 직접 요청해야 하므로 불편할 수 있음.

🔥 정리! 푸시 vs 풀 (한 줄 요약)

방식	동작 방식	장점	단점
Push (푸시)	데이터가 변경되면 바로 전달	실시간 반응성	불필요한 데이터까지 받을 수 있음
Pull (풀)	필요할 때만 직접 요청 !MEMO : 데이터가 변경되었다는 사실만 전달 > 필요하면 가져다가 써	불필요한 업데이트 방지	실시간 업데이트가 불편할 수 있음

⛈️ 풀 방식으로 코드 바꾸기

값이 변했다는 알림을 옵저버가 받았을 때 주제에 있는 게터 메소드를 호출해서 필요한 값을 당겨오도록 만들 수 있다.

✅ 1. 주제에서 알림 보내기

1. 옵저버의 update 메소드를 인자 없이 호출하도록 WeatherData의 notifyObservers() 메소드를 수정한다.

	public void notifyObservers() {
		for (Observer observer : observers) {
			observer.update();
		}
	}

✅ 2. 옵저버에서 알림 받기

1. Observer 인터페이스에서 update() 메소드에 매개변수가 없도록 서명을 바꿔준다.

	public interface Observer {
		public void update()
	}

1. 마지막으로 update() 메소드의 서명을 바꾸고 WeatherData의 게터 메소드로 주제의 날씨 데이터를 가져오도록 각 Observer 구상 클래스를 수정한다.

	public void update() {
		this.temperature = weatherData.getTemperature()
		this.humidity = weatherData.getHumidity()
		display()
	}

---

⛈️ 라이브러리 속 옵저버 패턴 알아보기

나: 옵저버 패턴 사용하는 라이브러리 알려줘 책에는 스윙 라이브러리 나오는데 아예 모르겠고 난 프론트엔드 개발자라 친숙한 거 추천해줘 거기서 어떻게 옵저버 패턴 쓰는지도 같이 알려줘

C선생: Zustand는 간결한 상태 관리 라이브러리로, subscribe 메서드를 통해 상태 변경을 감지하고 특정 동작을 수행할 수 있음

• 옵저버 패턴을 적용한 예시: store.subscribe(callback)을 사용하여 상태 변경을 감지 가능

🔍 Zustand에서 옵저버 패턴이 어떻게 적용되었을까?

✅ subscribe()을 활용한 상태 감지

Zustand는 상태가 변경될 때 이를 구독(subscribe)하고, 구독한 컴포넌트만 업데이트하는 방식을 사용한다

import { create } from 'zustand';

// Zustand 스토어 생성
const useStore = create((set) => ({
  count: 0,
  increase: () => set((state) => ({ count: state.count + 1 })),
}));

// 구독(subscribe) 기능 활용
const unsubscribe = useStore.subscribe((state) => {
  console.log("📢 상태 변경 감지:", state.count);
});

// 상태 변경
useStore.getState().increase(); // 콘솔: 📢 상태 변경 감지: 1

// 구독 해제
unsubscribe();

🧐 옵저버 패턴의 핵심

• useStore.subscribe((state) => {...}) → 상태 변화 감지 후 특정 동작 실행
• unsubscribe() → 필요 없을 때 구독 해제

🚀 Zustand에서 옵저버 패턴을 쓰는 이유

1. 불필요한 렌더링 방지: 특정 상태를 구독한 컴포넌트만 업데이트됨.
2. 리액티브한 상태 관리: 상태 변화 감지 후 자동으로 반응.
3. 전역 상태 관리가 간편: Redux보다 코드가 간결하고 직관적임.
4. 구독 해제 기능 지원: 불필요한 구독을 정리할 수 있어 성능 최적화 가능.

Zustand가 Redux, Context API보다 가볍고 효율적인 이유는 바로 옵저버 패턴을 활용한 구독 시스템 덕분이다.

---

⛈️ Reference

https://velog.io/@akimcse/%ED%97%A4%EB%93%9C-%ED%8D%BC%EC%8A%A4%ED%8A%B8-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-02.-%EC%98%B5%EC%A0%80%EB%B2%84-%ED%8C%A8%ED%84%B4

https://greensky0026.tistory.com/264?category=1002449