[디자인패턴] OBSERVERPATTEN(옵저버패턴) 

 

안녕하세요. 예지우랑입니다.

디자인패턴중 제일 처음에 나오는 observer(옵저버)패턴에 대해 알아보겠습니다.

(※ 이 포스팅의 내용과 예제는 한빛미디어의 HEAD FIRST DESIGN PATTERNS를 참조하여 작성하였습니다.)

 

1. OBSERVERPATTEN 

 

-정의 : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들테 연락이 가고 자동으로 내용이 갱신되는 방식으로

            일대다(一對多 , one to many)의존성을 정의합니다.

-장점 : 주제 객체의 상태변화를 자동으로 알려주어 의존하는 다른객체를 동적으로 변화시킬 수 있다.


2.예제


사실 옵저버 패턴은 매우 간단합니다.

위의 정의가 전부입니다.

하지만 좀더 정확히 하기위해서 가벼운 예제를 들어보기로 합시다.


여러분이 농장 주인이라고합시다.

여러부는 농장의 동물들에게 밥을 주는대 매번 밥을 주러 사육장을 돌아다니기 귀찮아서 

사육장에 스피커를 연결해놓고 급식장에 밥을 준비한 후 벨을 울려서 동물들에게 밥이 나왔다는것을 알려줍니다.

그림 1. 처럼 말이죠

그림1. 주제와 옵저버


그림1.처럼 여러분이 급식송 밥을주면 각 사육장으로 알려주게 됩니다.

그러면 동물들은 밥을 먹으러 오게 되겠죠??


여기서 여러분이 '주제'객체이고 각 동물들은 '옵저버 그룹'에 속해있는 '옵저버 객체'가 됩니다.

여러분(주제)가 벨을 울리는 행위를 '주제'객체가 '옵저버'객체에게 상태가 업되이트 되었다는것을 알려주는 것이죠.


그런데 사업 확장을 위하여 어제부터 키우기 시작한 오리는 옵저버 그룹이아니어서(사육장에 벨이 없어서) 밥을 못먹는

구조네요. 

불쌍항 오리를 위하여 그림2.처럼 오리를 옵저버 그룹에 등록시켰습니다.





그림 2.  새로운 객체가 옵저버에 추가됨.


오리를 옵저버그룸에 등록(register)하여 이제 오리도 벨소리를 듣고 밥을 먹으러 올 수 있게 되었습니다.

농장을 운영하다보니 우리의 개들이 밥을 너무 많이먹고 운동이 부족하여 돼지가 되었습니다.


돼지는 아직 사육할 계획이 없는데, 돼지가 있으니 난감한 여러분은 각종 성인병의 원이이되는 비만을 치료하기 위하여

개에게 당분간 먹이를 주지 않기로합니다.


그림3. 처럼 말이죠



그림 3. 옵저버 그룹에서 특정 객체를 제거.


여러분은 개 사육장에 연결된 벨에 전선을 끊어버렸습니다.(remove)이로 인해서

이제 개들은 다시 옵저버 그룹에 등록(register)되기 전까지는 밥을 못먹게 되었네요.


이렇게 옵저버 패턴을 이용하여 여러분은 농장의 동물들의 체중을 쉽게 조절하면서 

농장을 운영할 수 있습니다.


위의 예에서 알 수 있는 옵저버 패턴의 특징은 

각 객체는 언제든 주제객체에 의존하는 옵저버 그룹에 가입하거나 탈퇴할 수 있다. 라는 것입니다.



개념 정리가 어느정도 되셨나요?

이제는 실제로 적용하는 코드르 보도록 합시다.


여러분은 프로젝트를 맡았습니다. 

프로젝트의 내용은 기상청에서 업데이트되는 기상정보중 기온, 습도, 기압을 이용하여 

사용자에게 실시간으로 알려주는 프로그램을 만드는 것입니다.


다행이 한국 기상청은 기상정보를 국민 모두가 볼수있게 공개하고 있으며, 

개발자들이 쉽게 쓸 수 있도록 API도 제공하고 있네요.


그림4.는 기상청이 제공하는 API에 있는 날씨정보 객체입니다.




그림4. 기상청이 제공해주는 API중 날씨정보 객체


getTemperature 메소드는 온도를,

getHumidity 메소드는 습도를,

getPressure 메소드는 기압을 각각 기상청에서 가저오는 메소드입니다.

measurementsChanged는 관측값이 갱신(그림엔 오타가있네요) 될때마다 알려주는 메소드입니다.


아래 코드1.에서 코드를 보도롭합시다.


 

public class WeatherData {
    //인스턴스 변수자리
    public void measurementsChanged(){
        //이미 구현되어있는 WeatherData의 getter method를 이용하여 최신측정값을 가져옴
       
        float temp = getTemperature();
        float humidity = getHumidity();
        gloat pressure = getPressure();
       
        currentContitionsDisplay.update(temp,humidity,presure);
        statisticsDisplay.update(temp,humidity,pressure);
        forecastDisplay.update(temp, humidity, pressure);
    }
//기타메소드
}

코드1. WhatherData 클래스


위의 코드에서 measurementChanged() 메소드를 구현해 봤습니다.

각 정보 업데이트 메소드를 이용해서 변수에 정보를 담은 후 

 currentContitionsDisplay.update(temp,humidity,presure);
        statisticsDisplay.update(temp,humidity,pressure);
        forecastDisplay.update(temp, humidity, pressure);
위의 세 메소드를 이용하여 우리가 기상정보를 보여줄 현재상태, 평균/최저/최고치 , 기상예보를 표시해주는
프로그램에(객체에) 정보를 보내주고 있습니다.

이쯤되면 눈치를 체시겠지만 우리는 기상청에서 제공해주는 API를 이용하여
현재 기상상태 , 평균/최저/최고치 , 기상예보 이렇게 세가지 정보를 유저들에게 제공해줄 생각입니다.
좀더 이해를 돕기위해 그림5.의 클래스 다이어그램을 보면서 살펴봅시다.


그림5. 옵저버패턴의 클래스다이어그램


먼저 Subject 부터 봅시다.


Subject는 주제를 나타내는 인터페이스입니다.

객체를 옵저버로 등록하거나 옵저버 목록에서 탈퇴시키고 싶을때는 이 인터페이스에 있는 메소드를 사용하면됩니다.

그다음은 Observer 인터페이스입니다.


Observer가 될 가능성이 있는 객체는 반드시 Oberver인터페이스를 구현해야 합니다.

이 인터페이스에는 주제의 상태가 바뀌었을때 호출되는 update()메소드밖에 없습니다.


각 주제마다 여러게의 Oberver가 있을 수 있습니다.


ConcreteSubject는 주제 역하을 하는 구상 클래스입니다.

항상 Subject인터페이스를 구현 해야하면 

주제 클래스에서는 등록 및 해지를 위함 메소드 웨에, 상태가 바뀔때마다 모든 옵저버들에게 연락을 하기위한

notifyObservers()메소드를 구현해야합니다.

또, 주제 클래스에는 상태를 설정하고 알아내기 위한 세터/게터 메소드가 있을 수도있습니다.


ConcreteObserver는 Observer인터페이스를 구현해야만 옵저버 클래스가 될 수 있습니다.

각 옵저버는 특정 주제 객체에 등록을 해서 연락을 받을 수 있습니다.


※의존성이란?

의존성이랑 한객체 또는 로직이 다른 객체의 상태에 따라 영항을 받는것을 이야기합니다.

옵저버패턴에서는 옵저버들이 주제 객체의 상태에따라 옵저버의 상태가 변하게되므로 

옵저번느 주제에대해 의존성을 가진다 라고 말합니다.


디자인원칙

 서롤 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합을 하는 디자인을 사용해야합니다.

느슨하게 결합하는 디자인을 사용하면 변경사항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있습니다.

객체 사이의 상호 의존성을 최소화 할 수 있기 때문이죠

 옵저버 패턴의 주제와 옵저버는 느슨한결합(Loose Coupling)을 하고 있습니다. 

옵저버 패턴이 느슨한 결합이라는 근거와 장점을 알아보고 갑시다.

근거1. 주제가 옵저베에 대해서 아는것은 옵저버가 특정 인터페이스를 구현한다는것 뿐입니다.

           다른걸 알필요도 없고 알고싶지도 않습니다. 

장점1. 옵저버는 언제든 새로 추가할 수 있습니다. 

          주제는 옵저버 인터페이스를 구현하는 객체에만 의존하기 때문에 언제든 새로운 옵저버를 추가할 수 있죠.

장점2. 주제와 옵저버는 독립적으로 사용할 수 있습니다.

          어차피 서로에 대해 아는것은 특정 인터페이스를 구현할 수 있다는 것 뿐이고 그외에는 서로 관심도 없습니다.

          옵저버가 새로운 행동을 하는것이 주제와의 관계에서 문제가 일어날거같다면

          그저 주제의 목록에서 삭제해 버리면 그만입니다.

장점3. 주제나 옵저버가 바뀌더라도 서로에게 영향을 미치지 않습니다. 

          서로 인터페이스를 구현한다는 조건만 만족되면 어떻게 바꿔도 문제가 생기지 않습니다.

         



이제 최종적으로 우리의 시스템을 구현하기 위한 클래스 다이어그램인 그림6.을 봅시다.



그림6. 우리가 구현하게될 기상정보시스템의 최종 클래스 다이어그램. (클릭하면커집니다.)


하나씩 설명을 해봅시다.

Subject는 주제 인터페이스입니다. 우리가 지금까지해온것과 동일합니다.

Obser인터페이스는 주제 객체에서 옵저버에게 생신된 정보를 전달할 수 있는 방법을 정의하게 만듭니다.

DisplayElement인터페이스는 우리의 기상 정보를 화면에 표시해주는 방법을 정의하게하는 인터페이스입니다.


WeatherData는 기상청에서 제공해주는 객체입니다. Subject를 Implement하여 우리의 시스템에서 새로 갱신된 날씨데이터를 

가져다 줍니다.

CurrentConditions는 현재 측정된값을 보여줍니다.

StatisticsDisplay는 평균/최고/최저값을 보여줍니다.

ForecastDisplay는 기상 예보를 표시해줍니다.

ThirdPartyDisplay는 위의 세가지 이외에도 Obsever와 DisplayElement만 구현하면 옵저버객체가되며 정보를 표시해줄 수 있다는것을

알려주는것입니다.



이제 구현을 해봅시다. 

 public interface Subject {

  public void registerObserver(Observer o);   //옵저버를 등록
  public void removeObserver(Observer o);     // 옵저버를 제거
  public void notifyObservers();              // 주 객체의 상태 변경시 모든 옵저버에게 알려주는 메소드

}

코드2. Subject Interface


 public interface Observer {

  public void update(float temp , float humidity, float pressure); 
  /*
   * 옵저버 인터페이스는 모든 옵저버 클래스에서 구현해야합니다.
   * 따라서 모든 옵저버는 update메소드를
   * 구현해야합니다.
   */
}

코드3. Observer Interface


public interface DisplayElement {

  public void display();
  /*
   * display화면을 출력해야할 경우 호출해야되는 메소드.
   */
}

코드4. DisplayElement InterFace


 import java.util.ArrayList;

public class WeatherData implements Subject {
	private ArrayList observers;    //ArrayList자료구조를 사용합니다. ArrayList를 import합시다.
	private float temperature;
	private float humidity;
	private float pressure;
	
	public WeatherData(){
	  observers = new ArrayList();    //생성자에서 observers를 생성 해 줍니다.
	}
	
	public void registerObserver(Observer o){  //옵저버가 등록을 하면 목록 맨뒤에 추가해줍니다.
	  observers.add(o);
	}
	
	public void removeObserver(Observer o){   //옵저버가 탈퇴를 요청하면 목록에서 제거해줍니다.
	  int idx = observers.indexOf(o);
	  if(idx >=0 ){
	    observers.remove(idx);
	  }
	}
	
	public void notifyObservers(){
	  for(int i = 0 ; i < observers.size(); i++){
	    Observer observer = (Observer)observers.get(i);
	    observer.update(temperature, humidity, pressure);
	  }
	}
	
	public void measurementsChanged(){
	  notifyObservers();
	}
	public void setMeasurements(float temperature , float humidity, float pressure){
	  /*
	   * 기상청에서는 날씨정보를 알려주는 API를 제공합니다.
	   * 그러나 여기서 적용시키자면 배보다 배꼽이 커지게되어 이 메소드를 통하여
	   * 확인해보도록하겠습니다.
	   * http://www.kma.go.kr/weather/lifenindustry/sevice_website.jsp
	   * 진짜 날씨정보를 제공해주는 프로그램을 만드시고싶다면
	   * 위의 페이지를 참조하여주세요.
	   */
	  this.temperature = temperature ; 
	  this.humidity = humidity;
	  this.pressure = pressure;
	  measurementsChanged();
	}
//기타메소드
}

코드5. 실제 구현한 WeatherData Class


 

public class CurrentConditionsDisplay implements Observer, DisplayElement {
  /*
   * WeatherData객체로부터 변경사항을 받이귀아혀 Observer객체를 구현합니다. 
   * API구조상 모든 디스플레이 항목에서 DisplayElement를 구현하기로 했기 때문에 
   * DisplayElement인터페이스도 구현합니다.
   */
  private float temperature;
  private float humidity;
  private Subject weatherData;
  
  public CurrentConditionsDisplay(Subject weatherData){
    /*
     * 생성자에 weatherData라는 주제객체가 전달되며 , 그 객체를 써서 디스플레이를 옵저버로 등록합니다.
     */
    this.weatherData = weatherData;
    weatherData.registerObserver(this);
  }
  
  public void update(float temperature, float humidity , float pressure){
    /*update()가 호출되면 기온과 습도를 저장하고 display()를 호출합니다.*/
    this.temperature = temperature;
    this.humidity = humidity;
    display();
  }
  
  public void display(){
    System.out.println("현재 기온:" + temperature + " | 현재 습도:" + humidity);
  }
}

코드6. CurrentConditionsDisplay클래스



/*테스트용 클래스입니다. 우리가 만든 프로그램이 잘 동작하는지 알아봅시다.*/
public class WeatherStation {
  public static void main(String[] args){
    WeatherData weatherData = new WeatherData(); 
    //우선 웨더 데이터 객체를 생성합니다.
    
    CurrentConditionsDisplay currentDisplay = new CurrentConditionsDisplay(weatherData);
    //현재값을 보여주는 클래스인 CurrentConditionsDisplay 객체를 생성합니다. 인자로 미리 생성한 웨더데이터 객체를 줍니다.
    
    weatherData.setMeasurements(80, 65, 30.5f);
    weatherData.setMeasurements(10, 20, 88.7f);
    weatherData.setMeasurements(65, 23, 10.5f);
    //세로운 기상 값이 들어간것처럼 만들어줍니다.
    
    
  }

}

코드7. 테스트를 위해서 main메소드를 만들어봤습니다. 한번 돌려봅시다.


최대/최저/평균을 구하는 staticsDisplay클래스와 

기상예보를 해주는 ForecastDisplay클래스는 여러분이 직접 만들어보시면 좋을거같습니다.!!!!




3. 옵저버패턴은 실제 어디에서쓰일까?

옵저버패턴은 일종의 push방식의 알고리즘입니다.

업데이트된 정보 또는 DATA를 처리하는 알고리즘에는 크게 PUSH방식과 PULL방식이 있습니다. 

물론 두가지를 결합한 형태의 방식도 존재하죠


지금 알아본 옵저버패턴은 일종의 push방식 알고리즘으로써 

상태가 바뀐값을 다른 객체에 알려주면서(push하면서) 그 값을 다른 객체가 처리하고있죠

제가 생각했을때 일상에서 가장 쉽게 접할수있는 시스템중에 옵저버 패턴을 적욕할 법한 시스템은

쇼핑몰입니다.

우리가 구매 버튼을 누른 후 결제를 하고면 자동으로 우리 이메일로

결제가 완료되었습니다. 라는 안내메일이 오잖아요?


여러 구현 방법이 있을 수 있겠지만 결제모듈을 주제 객체로, 메일링 시스템을 옵저버 객체로 등록해놓고 

결제완료시에 update()메소드를 호출하면 자동으로 메일링 시스템이 메일을 보내주겠죠?



4. 최종적으로 옵저버패턴의 핵심을 다시 봅시다.

OBSERVERPATTEN 

 

-정의 : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들테 연락이 가고 자동으로 내용이 갱신되는 방식으로

           일대다(一對多 , one to many)의존성을 정의합니다.

-장점 : 주제 객체의 상태변화를 자동으로 알려주어 의존하는 다른객체를 동적으로 변화시킬 수 있다

옵저버 패턴의 특징 

각 객체는 언제든 주제객체에 의존하는 옵저버 그룹에 가입하거나 탈퇴할 수 있다.





※의존성이란?

의존성이랑 한객체 또는 로직이 다른 객체의 상태에 따라 영항을 받는것을 이야기합니다.

옵저버패턴에서는 옵저버들이 주제 객체의 상태에따라 옵저버의 상태가 변하게되므로 

옵저번느 주제에대해 의존성을 가진다 라고 말합니다.


디자인원칙

 서롤 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합을 하는 디자인을 사용해야합니다.

느슨하게 결합하는 디자인을 사용하면 변경사항이 생겨도 무난히 처리할 수 있는 유연한 객체지향 시스템을 구축할 수 있습니다.

객체 사이의 상호 의존성을 최소화 할 수 있기 때문이죠

 옵저버 패턴의 주제와 옵저버는 느슨한결합(Loose Coupling)을 하고 있습니다. 

옵저버 패턴이 느슨한 결합이라는 근거와 장점을 알아보고 갑시다.

근거1. 주제가 옵저베에 대해서 아는것은 옵저버가 특정 인터페이스를 구현한다는것 뿐입니다.

           다른걸 알필요도 없고 알고싶지도 않습니다. 

장점1. 옵저버는 언제든 새로 추가할 수 있습니다. 

          주제는 옵저버 인터페이스를 구현하는 객체에만 의존하기 때문에 언제든 새로운 옵저버를 추가할 수 있죠.

장점2. 주제와 옵저버는 독립적으로 사용할 수 있습니다.

          어차피 서로에 대해 아는것은 특정 인터페이스를 구현할 수 있다는 것 뿐이고 그외에는 서로 관심도 없습니다.

          옵저버가 새로운 행동을 하는것이 주제와의 관계에서 문제가 일어날거같다면

          그저 주제의 목록에서 삭제해 버리면 그만입니다.

장점3. 주제나 옵저버가 바뀌더라도 서로에게 영향을 미치지 않습니다. 

          서로 인터페이스를 구현한다는 조건만 만족되면 어떻게 바꿔도 문제가 생기지 않습니다.

         



다음번엔 또 새로운 패턴으로 돌아오겠습니다. 감사합니다.






[디자인패턴] STRATEGY(전략패턴) 

 

안녕하세요. 예지우랑입니다.

디자인패턴중 제일 처음에 나오는 STRATEGY(전략)패턴에 대해 알아보겠습니다.

(※ 이 포스팅의 내용과 예제는 한빛미디어의 HEAD FIRST DESIGN PATTERNS를 참조하여 작성하였습니다.)

 

1. STRATEGY PATTEN 

 

-정의 : 알고리즘군을 정의하고 각각을 캡슐화하여 교환하여 사용할 수 있도록한다.

-장점 : 전략패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

 

2. 예제

※예제를 통하여 전략패턴에 대해 알아보도록 하겠습니다.

 

-연못의 오리를 보여주는 프로그램이 있습니다.

  우리는 객체지향의 장점을 활용하기 위하여 'Duck'이라는 SuperClass를 만들어놓고 오리 객체를 만들어서 

 화면에 보여주고있습니다.

 

 

 

 

그림1. Duck SuperClass와 그 클래스를 상속받는 오리 클래스

 

그림1과 같은 구조로 Duck이라는 SuperClass를 선언하여 오리의 기본적인 기능을 정의 해놓고

 자식클래스를 이용하여 변경부분을 조정하여 오리들을 만들고 있습니다.

그런데 이때 우리의 클라이언트가 오리가 날수있게 만들어달라고했습니다.

그래서 아래와 같이 Duck클래스를 수정했죠


그림2. fly 매소드를 추가한 Duck 클래스와 그 클래스를 상속받는 기타 오리 클래스들

 

우리는 아주 쉽게 문제를 해결한거같이 보였지만, 클라이언트는 '고무오리'를 추가해달란 요청을 했습니다.

여기서 문제가 발생하게 되죠




그림3. 고무오리 클래스가 추가된 Class Diagram

 고무오리를 그대로 추가했더니 고무오리가 갑자기 일바오리처럼 '꽥꽥'소리를 내면서 '날기'시작했습니다.

 고무오리가 난다는것은 말도안되며, 일반적으로 고무오리는 '삑삑'소릴르 내기때문에  오버라이드를 통해서 해결했습니다.

 


그림4. 고무오리와 나무오리 클래스

새로 추가된 나무오리도 오버라이드를 통해서 날아다니거나 이상한 소리를 내는것을 막았습니다.

그런데 이런 오리가 추가될때마다 우리가 일일이 오버라이드를 해야한다면 과연 '객체지향'의 이득을 잘 살린 코드라고 할 수 있을까요?

수정사항이 발생하면 코드를 일일이 수정하여야하고, 새로운 오리가 추가될때만다 많은 코딩을 하는것은 바람직하지 않아보입니다.

그래서 Interface를 사용하기로 결정했습니다.



그림5. 인터페이스를 사용한 오리시스템

모든 Duck클래스의 서브클래스 오리들이 날거나, 울거나 하는것은 아니기때문엔 인터페이스로 빼내서 활용하기로했습니다.

이렇게 했을때 일부문제(고무오리, 나무오리가 날아다니거나하는 이상한일)를 해결할 수는 있지만

모든 클래스들에서 인터페이스는 구현해줘야하기때문에 오히려 복잡해지게 됩니다.

따라서 이방법을 사용하느니 차라리 오버라이드를 해주는 방법이 좋을거같습니다.

여기서 디자인 패턴의 원칙이 하나 나옵니다.

 

 

 디자인 원칙!

 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리 시킨다.

  현재 우리의 오리 프로그램에서 달라지는 부분은 fly() 와 quack()입니다.

 따라서 우리는 해당 메소드를 추출하여 각각의 행동을나타내는 클래스 집합으로 만들것입니다.

 



그림6. Duck 클래스에서 추출한 Fly 클래스와 그를 이용해 새로 만든 Duck클래스

 

위의 Diagram을 보시면 Duck클래스에서 바뀌는 부분들을 뽑아 냈습니다.

Fly 와 , Quack이죠 대표적으로 Fly를 Flayable이라는 인터페이스를 상속시켜 각각 나는 방법을 구현했습니다.

그결과 날개로 나는 FlyWithWings클래스와 날지않는 FlyNoWay클래스가 만들어졌죠,

그리고 만들어진Duck은 그림 7,8과 함께 설명 해 드리겠습니다.

 

 

그림7. 바뀌는 부분을 추출한 QuackBehavior와 FlyBehavior인터페이스

 

각각 인터페이스를 이용하여 그것을 상송항 클래스를 구현했는데요 여기에서 또다시 디자인 원칙이 나옵니다.

 

 

 디자인 원칙!

 구현이 아닌 인터페이스에 맞춰서프로그래밍한다.

  인터페이스에 맞춰서 프로그래밍 한다는것은 상위 형식에 맞춰서 프로그래밍 한다는 것을 뜻합니다.

여기서 인터페이스는 중의적으로 쓰였는데, 자바의 INTERFACE구조를 지지항기도하고, 상위형식에 맞춰 프로그래밍을 하여

다형성을 화용해야한다는것입니다.

객체를 변수에대입할때 상위형식을 구체적으로 구현한 형식이라면 어떠한 클래스에도 집어넣을 수 있고, 선언하는 클래스에서 실제 객체의 형식을 몰라도 되기때문입니다. 




그림8. Animal인터페이스를 이용한 Dog클래스와 Cat클래스

 

여기서 구현에 맞춰 프로그래밍하는것과 인터페이스에 맞춰서 프로그래밍 하는것을 알아봅시다.

 

Dog d = new Dog();

d.bark();

 

위의 코드는 구현에 맞춰서 프로그래밍 한것입니다.

d는 Dog클래스를 선언한것으로 구체적 구현에 마ㅈ춰져 코딩한것입니다.

 

Animal animal = new Dog();

animal.makeSound();

 

위의 코드는 인터페이스에 맞춰서 프로그래밍 한 것입니다.

'다형성'덕분에 상위 클래스에 해당하는 변수는 하위 클래스 객체를 담을 수 있습니다.

 

이렇게 인터페이스에 맞춰서 프로그래밍을 한다면 사용을할때 해당 변수에 적절한 객체(클래스)를 

대입하여 사용할 수 있겠죠?

 

이제 다시한번 확인 해 봅시다.

 

그림9. 새로 만든 Duck클래스

 

새로만든 덕 클래스에는 아까 만든 FlyBehavior 인터페이스에 해당하는 변수와 

QuackBehavior 인터페이스에 해당하는 변수가 만들어 졌습니다.

그리고 fly() 메소드와 quack()메소드 대신 performFly()메소드와 performQuack()메소드가 들어있습니다.

두 메소드의 구현을 살펴봅시다.

 

public void performFly() {

  flyBehavior.fly();   

}

 

public void perfromQuack(){

  quackBehavior.quack();

}

 

위의 두 메소드에서는 변수로 가지고있는 클래스의 메소드를 이용하는 클래스를 사용하여

행동을 합니다. 

이렇게하면 Duck클래스는 울거나 날수있지만 그동작이 어떻게 이루어지는지는 전혀 알 필요가없습니다.

이는 자바의 '캡슐화'입니다.

어떻게 동작이 이루어지던지 전혀 상관없고 단지 할 수 있다는것이 중요한 것이죠.

 

 

이제부터는 구현을 한번 해봅시다.

 


















※ quack은 상위클래스(인터페이스)를 , fly는 구체적인 자식클래스를 변수에 담아보기로합니다.


 

최종적으로 시뮬레이터를 통하여 테스트해본결과 원하는 대로 나오게됩니다.

 

 

이번에는 나는 방법을 동적으로 추가해보기로합시다.

 

먼저 덕클래스에 동적으로 지정하기위한 메소드를 추가합니다.

 



모델 덕 클래스를 새로 만듭니다.


로켙을 이용하는 Fly를 클래스를 만듭니다.



시뮬레이션을 수정하여 다시한번 실행 해 봅시다.

 

 

 

 

지금 까지 만들었던 오리 프로그램을 크게 바라봐봅시다.


파란 부분은 클라이언트/ 빨간부분은 오리의 행동을 캡슐화시킨 것들이죠

 

디자인 패턴에서 오리의 행동들은 '알고르즘' 혹은 '로직' 이라고 생각하시면 좋습니다.

우리는 A는 B이다 보다는 A에는 B가 있다 라고 생각을 하는것이 좋습니다.

A에 B가있다라는 관계를 오리 프로그램에서 생각 해 보면 

오리에는 FlyBehavior 와 QuackBehavior가 있으며, 각각 행동들(알고리즘 혹은 로직)을 위임받습니다.

 

두 클래스를 이런식으로 합치는것을 구성(composition)을 이용한다고 합니다.

 

오리클래스에서 생송을 상속받는 대신 올바른 행동 객체로 구성함으로써 행동을 부여받게 됩니다.

 

여기서 또다른 디자인 원칙이 나옵니다.

 

 

 

 디자인 원칙!

 상속보다는 구성을 활용한다.

 구성을 이용하여 만들면 유연성이 크게 향상되며캡슐화를 통하여 유지/보수시에 코드수정을 최소화 할 수 있습니다.

 

 

마지막으로 지금까지 본 스트래지티 패턴(STRATEGY PATTERN)의 정의를 한번 더 말씀드리자면

스트래지티 패턴(STRATEGY PATTERN):

알고리즘군(로직)을 정의하고 각각을 캡슐화하여 교환하여 사용할 수 있도록 만든다. 

이 패턴을 사용하면 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

+ Recent posts