2.Observer Pattern

문제제기

 

- 위처럼 기상 모니터링 애플리케이션을 만든다고 가정해보자.
- WeatherData 자체는 기상측정소에서 가져온다.
- 우리는 어플리케이션에서 총 3가지 어플리케이션을 구현해야한다
 1)번 디스플레이에는 기상통계를 보여준다.(평균, 최고 최저기온)
 2)번 디스플레이에는 현재 조건을 보여준다. (기온, 습도, 기압)
 3)번 디스플레이에는 기상 예보를 보여준다(기온)
- 우리는 위에 조건을 가진 디스플레이를 어떻게 확장가능하게 보여줄 수 있을까?

- 다음과 같이 프로그래밍을 한다고 가정해보자

public class WeatherData {
	public void measurementsChange() {
    	float temp = getTemperature();
        float humidity = getHumidity();
        float pressure = getPressure();
        
        display1.update(temp, humidity, pressure);
        display2.update(temp, humidity, pressure);
        display3.update(temp, humidity, pressure);
    }
	//....
}

 

- 위처럼 만들수는 있겠지만, 무엇인가 유연하지 않다. 그리고 전에 배웠던 디자인패턴의 원칙과는 동떨어져보인다

 

- 코드에서 전에 배웠던 디자인 패턴 원칙에 따라 구분지어보니, 바뀔수 있는 부분과, 바뀌지 않는 부분을 나눠보았고. 공통된 update라는 기능을 추출해보았다.

 

 

Observer 패턴에 대한 개요

- 위 기상모니터링 애플리케이션 코드를 리팩토링하기전에 Observer 패턴에 대해서 먼저 알아보자,

- 위 그림처럼, Subject 객체가 데이터를 전달하는 주체이고, Observer 객체들은 그 주제들을 전달받는 객체인것만 알면 Observer 패턴에대해서 모두 이해한 것이다. 그리고 Observer들은 언제든지 구독과 구독취소를 실행할 수 있다.

- 또한 옵저버 패턴은 Subject와 Observer사이에 일대다(one-to-many) 의존성을 갖는다.

- 위 그림에서 Subject 객체와 Observer 객체는 Loose Coupling 하다고 불수있다.
 1) Subject 객체가 옵저버에 대해 아는 것은 옵저버가 특정 인터페이스만 구현한 것만 알 수있다.
 2) 옵저버는 언제든지 추가, 삭제 될수있다.
 3) 새로운 형식의 옵저버를 추가하려고 할때, Subject를 전혀 변경할 필요가 없다.
 4) Subject와 Observer는 독립적으로 재사용 될 수있다.
 5) 주제와 옵저버의 코드가 변경되더라도 Code에 대한 Side effect가 없다.

디자인 원칙
서로 상호작용을 하는 객체 사이에서는 가능하면 느슨한 결합을 하는 디자인을 사용해야한다.

 

 

Observer 패턴을 기상 어플리케이션에 적용

-위와 같은 형태로 클래스 다이어그램을 만들 수 있을것이다.

 

public class WeatherData implements Subject{
	
	private ArrayList<Observer> observers;
	private float humidity;
	private float temperature;
	private float pressure;
	private Random random;
	
	
	public WeatherData() {
		observers = new ArrayList<Observer>();
	}

	@Override
	public void notifyObserver() {
		observers.stream().forEach(o -> o.update(temperature, humidity, pressure));
	}
    
    // ... omit
}

-WeatherData 객체에서 notify 하는 코드에 대해서만 보자면 위와같이 프로그래밍 할 수 있을것이다.