OOP 를 접할 때, 처음 다루는 내용 중 한 가지는 데이터와 기능을 한 단위로 관리하자는 Object(객체)의 가장 중요하고 기본이 되는 패러다임입니다.

이 때 객체 내부에서 관리하는 데이터를 객체의 상태라고 말할 수 있으며, 객체의 상태에 따라 분기처리를 이용하여 해야할 기능을 각각 구현 하는 경우는 많았을 것입니다.

이를테면, 아래와 같이 말이죠..

심플한 구현이지만, OOP 의 철학에서는 이와 같은 분기처리에 대해 꽤 경계를 하는 듯 합니다.

(OOP 철학에서는 분기처리를 다형성(polymorphism)으로 대체할 수 있음을 강조하고 있습니다.)

이전의 다뤘던 OOP 관련 많은 포스팅에서 간접적으로 분기를 대체하는 방법론들을 다뤄왔지만, 

이번 포스팅에서는 조금 더 본질적인 '왜 분기처리를 경계 해야하는가?' 에 대한 이유와 함께 객체의 내부상태를 OOP 관점에서 관리하고자한 상태 패턴(State-Pattern)에 대해 다뤄보려고 합니다.

오늘도 역시 요구사항으로 시작합니다.

1. 요구사항

RPG 의 성공적인 신화를 거둔 N사에 취직한 당신은, 그 희망처럼 신규로 제작협의가 된 프로젝트로 발령이 났습니다.

큰 기대에 부푼 당신!

메인 디렉터는 당신의 열정을 알아보고 첫 번째 미션을 맡겼습니다.

그것은 바로 "NPC 의 호감도" 구현입니다.

Player 는 NPC 에게 특정 액션을 취할 수 있고, NPC 들은 Player 의 호감상태에 따라 반응이 달라집니다.

(예를들면, NPC 들이 대화주제에 개인사가 더 포함하거나, 비밀상점을 열어주는 등)

Player 가 NPC 에게 할 수 있는 액션은 정해져 있으며(대화하기, 선물주기 등), 수행한 액션수에 따라 NPC 의 호감도가 결정되며 그에 따라 액션을 수행합니다.

일단, 너무 많은 수를 고려하지 않고 NPC 한 명에 대한 프로토 타입을 목표로 하려 합니다.

2. 객체 내부 변수와 그에 따른 행동.

요구사항 명세를 먼저 살펴볼 때, 명확한 한가지 사실은 Player 가 NPC 에게 취했던 액션의 횟수를 기록해야 한다는 것입니다.

그렇기 때문에, NPC 클래스 내부의 멤버변수로 액션의 횟수를 다음과 같이 기록하고자 합니다. 

내부 멤버변수를 변화시킬 수 있는 메소드도 같이 말이죠.

이제, 각 액션에 대한 구체적인 행위(NPC::talkWithHim, NPC::giftToHim)를 구현해 보죠.

조금 더 구체적인 요구사항인 행위 횟수에 따른 호감도는 다음과 같습니다. 

- 대화횟수 20 초과 일 때

- 선물횟수 10 초과 : 호감

- 선물횟수 10 이하 : 비호감

- 대화횟수 20 이하일 때 : 기본

이에 따라, 구현은 아래와 같습니다.

행위 횟수에 따라 잘 구현이 되었지만, 코드 중복이 다수 보입니다.

아직은 NPC 에게 할 수 있는 액션이 별로 없기 때문에 상관이 없지만, 요구사항이 추가되었을 때 그만큼 코드중복이 생길 것입니다.

코드 중복이 생기는 만큼, 추 후 수정을 할 때 모두 찾아 고쳐야 함을 의미합니다.

이는 유지보수에 쉽지 않다는 것을 의미합니다. ㅡㅡ^

이를 리팩토링하기 위하여, 크게 생각하지 말고 복잡한 if-else 관계부터 캡슐화해보죠. 

3. 코드(CODE)를 이용한 리팩토링

복잡한 if-else 관계이지만, 우리는 이를 살짝 리팩토링할 수 있을 것 같습니다.

NPC 는 호감도라는 일종의 상태를 따로 가지고 있으며, 해당 상태에 따라 적절한 행위를 하도록 하는 것이죠.

추상적인 개념인 호감도는 코드 로써 정의를 할 것입니다.

(현재 구축할 코드는 호감, 비호감, 기본상태 정도인 듯 합니다.)

코드 개념을 도입해서 진행한 리팩토링은 다음과 같습니다.

이 리팩토링으로 인해, 오히려 NPC 클래스의 라인은 늘어났습니다. 

그렇다고 코드 중복이 없어진 것도 아닙니다. 

하지만 복잡한 if-else 상태에 대한 유연함을 가져올 수 있습니다.

오직 NPC::generateConfig 만 수정을 함으로써, 분기구문을 관리할 수 있습니다.

즉, 코드를 이용하여 일종의 캡슐화를 했다고 할 수 있습니다.

또한 코드 사용 부분의 가독성이 좋아졌습니다.

호감도 상태에 따라 무슨 일을 해야한다는 것이 명확하게 보이지 않나요? @.@

하지만, 여전히 코드를 사용하는 곳은 거슬립니다.

복잡한 코드의 사용을 단순화한 것은 좋아보이지만, 호감도 상태코드의 수정은 쉽지 않을 것 같습니다. 

(호감도 추가, 삭제를 위해서는 코드를 사용하고 있는 switch 상태를 점검해야할 것입니다.)

이 구문에서 제기한 문제는 단순히 코드 중복으로 인해 중복된 부분을 모두 고쳐야 하는 유지보수성의 문제만을 이야기한 것은 아닙니다.

오직 코드를 사용하는 곳이 한 곳이라도, 코드종류의 변경은 이미 작성된 로직 수정을 불러옵니다.

그 이유는 "코드라는 자체 조건"에 의해 분기하여 행위를 하기 때문이죠.

즉 분기의 사용은 '확장 개발을 해야할 경우, 기존 로직의 수정은 필수' 라는 의미를 내포하고 있으며, 이는 프로그램 확장성에 부담을 줄 수 밖에 없습니다.

SOLID 규칙 중, '수정에는 닫혀있고, 확장에는 열려있어야 한다.(OCP)' 는 언제나 이런 사실을 견제합니다.

OOP 에서는 이러한 분기로직을 대체할 개념으로 다형성을 말합니다. 

하지만 우리는 이를 이용한 개념은 전혀 생소하지 않을 것입니다. 이와 비슷한 문제를 풀어본 적이 있기 때문이죠.

바로 아래 내용에서 말이죠. :-)

'전략패턴' 에서 코드 사용문제를 다뤄본 것과 같이, 상태에 따른 행위를 위임하는 것으로 이 문제를 해결해 볼 수 있을 것 같습니다.

4. 상태에 따른 행위 캡슐화

상태에 따라, 해야할 일은 일단 두 가지 정도 되는 것 같습니다. (대화하기, 선물주기)

이에 따라 저는 다음과 같은 추상적인 클래스를 제작하였습니다.

이를 이용하여, 각 호감도에 대한 구체화 클래스를 제작할 수 있을 것 같습니다.

아래는 추상적인 호감상태를 구현한 구체화 클래스들입니다.

기존, 코드의 상태따라 switch 로 분기되어 처리되었던 행위를 캡슐화하였습니다.

이제 NPC 클래스들이 캡슐화된 상태 클래스들을 사용하도록 리팩토링해보죠.

일단, 기존에 관리하던 코드는 제거할 생각입니다.

구체화된 상태클래스들이 그 역할을 대신할 수 있을 것 같습니다.

저는 아래와 같이 구현을 해보았습니다.

예상대로, 코드가 대체 되었고 상태에 따라 행위를 수행할 수 있도록 하였습니다.

이는 상수를 이용하여 코드를 사용하는 것에 비해, 보다 명백하게 상태를 나타낼 수 있습니다. 

또한, 상태에 따라 다른 행위를 위임할 수 있습니다. 

즉 상태에 따른 분기를 제거했으며, 이는 추 후 상태 추가에 대한 부담이 적음을 의미할 수 있습니다.

이 방식을 OOP 에서 말하는 상태패턴에서는 Context-driven 이라고 합니다.

주제(NPC)가 주체적으로 상태(feeling)를 변경하는 것을 의미하죠. 전략패턴과 매우 유사합니다.

물론, 상태가 스스로 변경하는 방식 역시 존재합니다. 

4. 상태의 전이 (Context-driven vs State-driven)

이번 절에서는 상태의 전이의 두 가지 방법에 대해 자세히 다뤄볼 예정입니다.

3절에서는 주체(Context)인 NPC 클래스가 특정조건에 대하여 상태를 변경하는 방식인 Context-driven 을 구현하였습니다. 

하지만, 현재 호감도 상태에 따라 전이 방식이 달라진다는 요구사항을 받았다고 가정해 봅시다.

예를들면, 현재 구현된 NPC::generateConfig 를 다음과 같이 변경해 볼 수 있습니다.

즉 NPC 의 행위 횟수에 고정적으로 상태가 변경되는 것이 아닌, 동적인 현재의 호감도에 따라 전이방식이 달라질 수 있다는 요구사항입니다.

복잡한 과정을 NPC::generateConfig 로 몰았으나, [호감도 방식이 추가,삭제] 될 때 이 복잡한 로직은 꽤 골칫덩이가 될 수 있습니다.

State-driven 방식은 이 문제를 해결할 수 있는 체크메이트(checkmate)가 될 수 있을 것 같습니다.

Context-driven 이 주체가 특정 조건에 따라 상태를 변경을 했던 반면, State-driven 은 구체화 된 상태 클래스에서 특정 상황에 따라 스스로 상태를 전이합니다. 즉 이 방식은 상태 변경 행위 역시도 구체화된 각 상태 클래스에게 위임하겠다는 것을 의미합니다.

상태 클래스가 주제의 현재상태를 변경하기 위해서는, 주제에 대한 정보를 알고 있어야 합니다. 

그렇기 때문에 각 상태 클래스들이 주제를 has-a 관계로 가지고 있어야 할 듯 합니다.

(이는, 주제와 상태가 서로 사용관계를 가지는 결합도 높은 관계가 될 수 있습니다..)

이를 반영하여, [추상적인 상태 클래스]부터 변경해보겠습니다.

추상 클래스의 생성자 및 각 메소드들의 서명이 변경 되었으니, 그에 따라 상태 클래스의 서명 역시 수정할 필요가 있습니다.

아래의 예제는 변경된 추상클래스의 필수조건을 반영하고, 상태 전이 기능을 담은 기본 상태의 구체화 클래스 입니다.

NPC 에 대한 정보를 구체화 상태 클래스들이 모두 알고 있기 때문에, 자유롭게 상태전이 및 정보 이용을 할 수 있는 것을 확인할 수 있습니다.

하지만, 현재 작성된 코드에서 조금 거슬리는 부분이 있습니다.

상태전이를 수행하는 아래 부분말이죠.. 

NPC 객체를 변경하기 위해 사용하는 setter, getter 사용이 귀찮고 부적절해보입니다.

이 방법은 단지 불편함뿐만이 아닌, 구체화된 상태 클래스들 사이에서도 의존관계를 높게 할 여지를 줍니다.

차라리, NPC 객체에서 상태전이 메소드를 제공해주고 상태에서 사용하는 것은 어떨까요? 

이렇게 말이죠..

어느정도 정리가 된 듯합니다.

이제 나머지 상태까지 서명을 변경한 뒤, NPC 메소드를 다음과 같이 수정해 봤습니다.

setter, getter, 상태전이 메소드(toChangeXXXX) 등은 생략했습니다. :-)

State-driven 방식을 이용함으로써, 주제에서 조건에 따라 상태를 전이하던 NPC::generateFeeling 이 필요가 없어졌습니다.

상태들이 스스로 조건에 따라 상태전이를 수행하며, 이는 복잡한 if-else 관계가 사라졌다는 점과 함께 상태들의 추가 삭제에 대한 유연성이 보다 높아졌음을 의미합니다.

예를들어 상태가 삭제될지라도, NPC에서 toChangeXXXX 메소드를 제공했기 때문에 해당 메소드를 빈 메소드로 만들어 사장(Deprecated)시키는 방법 생각해 볼 수 있습니다.

단순히 이 방법만으로, 삭제된 상태를 의존하고 있던 다른 형제 상태들을 수정하지 않아도 됩니다.

(아, 물론 나중에 추 후 리팩토링할 경우 사장된 메소드는 지워주면 좋겠죠...)

State-driven 은 Context-driven 에 보다 더 유연한 것처럼 보입니다.

결과적으로 보면, OOP 에서 지양하는 분기처리를 대부분 다형성으로 처리할 수 있지 않았나요?

하지만 상태전이에 대한 요구사항이 일정 값에 의해 고정적으로 전이되는 구조 였다면, State-driven 은 좋은 선택이 되지 못했을 것입니다.

고정적으로 전이한다는 것은 NPC::generateFeeling 와 같은 구현내용이 어딘가에 꼭 존재해야함을 의미합니다. 

그렇기 때문에 Context 인 NPC 클래스에서 주체적으로 상태를 변경했었죠..

즉, 어떤 특정방식이 좋다는 것이 아닌 프로그래머가 요구사항 따라 적절한 방법을 사용해야합니다.

5. 열거형을 통한 Bird-Eyes-View 확보.

자바의 열거형(Enum)을 이용하면, 꽤 재미있는 것을 많이 해볼 수 있는 것 같습니다.

전략패턴 역시, 열거형을 이용하여 구현을 할 수 있었죠.

상태패턴은 구조적으로 전략패턴과 비슷하기 때문에 이 역시 열거형을 이용하여 구현할 수 있습니다.

이번 절에서는 앞서 구현했던 상태들을 열거형으로 구현해보는 것을 해볼 생각입니다.

물론 열거형으로 구현하는데 있어, [Context-driven, State-driven] 모두 가능합니다. 

- Context-driven 구현

먼저 구현해볼만한 사항은 Context-driven 입니다.

Context-driven 방식은 Context 가 상태를 전이하기 때문에 이에 대해 고려를 하지 않아도 됩니다.

이 곳에서 해야할 일은 상태에 대하여, 위임받게 될 행위를 적절하게 구현하는 것이죠.

이에 대한 구현 사항은 아래와 같습니다.

전략패턴에서 다뤘던 열거형을 이용한 방식과 크게 다르지 않습니다.

Context 에서 사용할 메소드의 서명에 위임할 행위를 상태마다 적절하게 구현하였습니다.

- State-driven 구현

State-driven 의 경우 구체화된 상태 클래스에서 Context 의 상태를 변경해야 합니다.

기존 구현 내용의 경우 Context 를 has-a 관계로 가지고 있었지만, 열거형에서는 아쉽게도 동적인 상태를 가질 수는 없습니다.

하지만, 안되는 것은 없습니다! :-)

각 열거형의 메소드 서명에는 Context 를 파라미터로 받는 방식으로 우회하면 되죠.

이를 반영한 열거형은 다음과 같습니다.

이로써 열거형으로 상태패턴을 구현하는 방법을 알아 보았는데요.

열거형을 이용하여 상태패턴을 구현하면, 제 생각에는 두 가지 정도의 장점이 있는 듯 합니다.

- 생산성

열거형을 이용하면, 굳이 클래스들을 많이 만들지 않아도 됩니다.

열거 타입만 추가해주면 되죠.

이는 꽤 생각보다 생산성을 올려줍니다.

- Bird-Eyes-View(조감도법) 확보

상태패턴의 각 상태는 다른 형제 상태들 사이의 관계에 있어서 꽤 의존적일 수 있습니다.

물론, 앞써 살펴본 예제에는 물리적으로 서로의 영역을 침범하지 않도록 Context 에서 상태전이를 직접적으로 수행하는 메소드들 제공 했었지만, 논리적인 의존성은 어쩔 수 없는 듯 합니다.

클래스의 개수가 많아졌다면, 그만큼 상태간의 논리적인 관계를 보기가 쉽지 않을 것입니다.

하지만, 열거형의 한 파일안에 모든 상태가 있고 이를 관리한다면 상태들의 관계를 살펴보기 훨씬 좋을 듯 합니다.

이는 단지 열거형뿐 아니라, 복잡한 VO 를 제작함에 있어서 각 변수들의 클래스를 내부 클래스로 선언함으로써 같은 효과를 볼 수 있습니다.

복잡한 관계들일 수록 조감도법은 꽤 유지보수에 도움이 될 것입니다.

6. 패턴 비교 (전략패턴 vs 상태패턴)

이번 리뷰에서는 계속하여 상태패턴 외에 전략패턴을 언급 했었습니다.

상태패턴과 전략패턴 모두 특정 주제가 어떤 조건에 의해 해야할 행위를 다형성을 이용하여 위임한다는 공통점을 가지고 있습니다.

즉, UML 을 비교한다면 두 패턴은 크게 다르지 않을 것입니다.

하지만 사용성 면에서 차이가 존재합니다.

전략패턴의 경우 '특정 메소드의 전략을 동적으로 변경하길 바라며, 이는 외부요인에 의해서 원할 때 변경'합니다.

상태패턴의 경우는 종종 한 주체(Context)가 제공하는 꽤 많은 기능들에 영향을 주며, 외부요인보다는 상태 스스로 변경되는 경우가 많습니다. 또한 전략 패턴에 비해 꽤 잦은 전이가 일어납니다.

그렇다고 '이 것은 상태패턴이야, 저 것은 전략패턴이야' 라고 외울 필요는 없을 듯 합니다. 

생각보다 꽤 긴 포스팅이 된 것 같습니다.

그 이유는 이번 포스팅은 꽤 작성하기 어려웠고, 그에 따라 생각이 많아졌기 때문인 듯 합니다.

특히, 이번에는 상태패턴 자체보다는 언제나 후배들에게 강조하던 분기처리에 대한 입장을 다뤄보고 싶었습니다.

언제나 [분기처리에 대한 경계]를 말하곤 했지만 그 이유에 대해서는 깊게 생각해보지 못했었고, 이번 포스팅을 계기로 그에 대한 고민을 많이 해보는 기회가 되었던 것 같습니다.

하지만, 글에 담겨져 있는지는 모르겠습니다. ^^;

마지막으로 상태패턴에 대한 재미있는 예제를 생각하지 못해 고민을 하던 중, 적절한 아이디어를 제공해준 '부사수 형오리' 에게 감사를 표하며 이번 포스팅을 마칩니다.

이 글이 읽는 분들에게 도움이 되었으면 좋겠습니다.