반응형

[디자인패턴] 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):

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

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

반응형

'프로그래밍 > 디자인패턴' 카테고리의 다른 글

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

+ Recent posts