스트래티지 패턴(Strategy Pattern)

알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만드는 패턴.

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

라고 책에서 말하고 있습니다.

패턴들을 알기위해 배운 첫번째 패턴입니다. (선방은 늘 기억에 남죠.. ^^)

책에서 오리의 예로 너무도 잘 설명이 되어있습니다만 제 나름의 정리를 위해 얼마전 업무를 위해 만들었던 상품들을

예로 들어 한번 설명해 보겠습니다.

제가 다니는 회사에서는 이통사의 부가 상품들을 주로 광고하고 가입시키는 업무를 많이 진행합니다.

키즈랜드. 문자사랑... 등등 월정액 상품들이 대부분이죠.

해당 상품들을 이렇게 설계했었습니다.
(사실 클래스 다이어그램으로 그려서 표현하고 싶은데(그게 당연하겠죠 ㅜㅜ) 당장 사용해본 툴이 하나도 없습니다.ㅜㅜ )

최상위클래스로 상품이라는 클래스를 두고 그안에 상품이 가지는 각종 행동들을 정의 했습니다.

가입, 탈퇴, 조회 등등의 행동들을 정의하고 실제 적용될 하위의 상품들은 상위 상품클래스를 상속받아서 구현을 했습니다.

최초 설계당시에는 세가지 정도의 상품이 있었고 제일 자주 사용이되는 부분은 가입부분이었습니다.

보통 구현을 할때 저희가 가입요청을 하면 실제 상품을 서비스해주는 회사에서 가입결과를 리턴해주는 방식인데

일반적으로 저희가 요청하는 형태로 결과를 리턴해 주었습니다.

그래서 슈퍼클래스인 상품 클래스에 가입메소드를 구현해두고 하위상품들은 이를 쉽게 이용했습니다.

그런데 상품이 추가될 수록 원래의 형태로 결과를 리턴해주지않는 회사들이 많아지고..

가입메소드를 오버라이드해서 새로 구현해야하는 하위상품들이 매우 많아졌습니다.

지금도 이상태 그대로 사용되고 있는데 각각의 상품들이 가입되는 방식들이 제각각인게 많아지다보니..

최초에 상속받아 사용할때의 편리함은 적어지고 오버라이드된 하위상품의 가입부분들중 같은 방식으로 구현되는

가입메소드는 중복되는게 또 많아 졌습니다. ㅜㅜ

이부분을 해결하는데 스트래티지 패턴이 도움이 될것 같습니다.

가입부분을 따로 분류해 여러가지 유형의 가입방법을 구현한 클래스들의 집합을 만들어

여러상품들이 각자에게 알맞는 가입유형을 가진 클래스를 이용해 가입을 하도록 리팩토링을 한다고 가정해 보겠습니다.

이전에 구현된 방식에 비해 나아진 부분들을 보면

이전에는 상속받은 가입메소드와 조금이라도 다른 가입유형을 가진 상품들은 무조건 오버라이드하여 새로 구현을 해야했습니다.

또한 오버라이드한 새로운 가입유형이 똑같이 반복이 되더라도.. 별다른 방법없이 중복되는 코드를 또다시 코딩해야 했지만

이제는 하나의 가입유형 클래스에 구현해두면 해당 가입메소드를 더이상 중복해서 코딩할 필요가 없겠습니다.

상품들을 가입시키기위한 유형들을 모두 구현했다면 그저 상품이 추가될때 골라 쓰기만 하면 되겠네요.

또 해당업체의 사정으로 가입하는 방식이 조금 변하게 되더라도 해당상품의 클래스를 수정할 필요없이 새로운 가입방법

을 적용할수도 있습니다. (가입유형을 가진 클래스는 어차피 수정을 해야하니.. 큰 차이는 없어보입니다.)

이외에도 책에서 설명해주는 부분들이 더 있지만 지금 와닿은건 이것밖에 없습니다. ㅜㅜ

장황하게 글로만 적어놓으니 다른사람이 보고 도움이 되기란... 거의 불가능해 보이네요 ...

빠른시간안에 클래스 다이어그램으로 한번 그려보도록 해야하겠습니다.