옵저버 패턴이란, 이름에서 알수 있듯이 관찰자, 즉 관찰하고 있는 대상이 변화할때마다 관찰자에게 이를 알리고 그에 맞게 행동하는 행동 패턴

• 일대다 의존성을 갖게된다
• Publisher/SubScriber 구조

관찰이라는 이름에서 능독적으로 관찰하고있느 것처럼 보이지만, 사실을 수동적으로 정보를 전달받는 것을 기다리는 것이라고 하는게 적절하다

구조

1. 대상자(Subject)와 관찰자(Observer)는 일대 다 관계
2. 대상자의 상태가 변하면 관찰자들에게 통보
3. 통보받은 관찰자들을 적절한 action을 취함(update)
4. 관찰자들을 언제든지 대상자의 그룹에 추가되고 삭제될 수 있다. 당연하게 그룹에 있으면 정보를 전달받고 그룹이 아니라면 정보를 전달받지 못한다.

사용 시기

• 특정한 케이스에만 다른 객체를 관찰해야 하는 경우
• 객체의 상태가 변경될때 다른 객체의 동작을 트리거 해야하는 경우
• 한 객체가 변하면 다른 객체도 변화시켜야 할때

장점

• 대상자(Subject)의 상태를 주기적으로 조회하지 않고 자동으로 감지 가능
• 관찰자와 대상자의 관계를 느슨하게 유지 가능

단점

• 알림 순서를 제어할 수 없다. 무작위
• 구조와 동작을 알아보기 힘듬, 코드 복잡도 증가
• 옵저버 객체를 등록 후에 해지않으면 메모리 누수

예시

클라이언트가 직접 유저들을 관리해서 유저의 클래스에 접근에서 display를 실행

public class Client {
    public static void main(String[] args) {
        WeatherAPI api = new WeatherAPI();

        List<IUser> users = new ArrayList<>();
        users.add(new KoreanUser("홍길동", api));
        users.add(new KoreanUser("임꺽정", api));
        users.add(new KoreanUser("세종대왕", api));

        // 온습도기에서 현재 상태의 온습도 정보가 갱신됨
        api.measurementsChanged();

        for(IUser u: users) {
            u.display();
        }

        api.measurementsChanged();

        // ...
    }
}

---

Subject와 Observer의 interface를 구현하고 이를 상속받음
Subject 인터페이스는 Observer들을 소유하고 있고 이 Observer들의 메서드를 위임받아서 호출

public class Client {
    public static void main(String[] args) {
        WeatherAPI api = new WeatherAPI();

        api.registerObserver(new KoreanUser("홍길동"));
        api.registerObserver(new KoreanUser("임꺽정"));
        api.registerObserver(new KoreanUser("세종대왕"));

        // 온습도기에서 현재 상태의 온습도 정보가 갱신됨
        api.measurementsChanged();

        // 알아서 전파되어 출력

        api.measurementsChanged();

        // ...
    }
}

measurementsChanged() 함수가 호출될때마다 이벤트를 감지하고 소유하고있는 Observer들의 내부 메서드를 실행

Observer의 관리를 Subject의 List로 관리한다는 점과 구독자들의 메서드를 위임받아서 이벤트가 발생할때마다 실행시키는 것이 핵심
=> Subject에서 Observer들을 관리하고 메서드를 실행