[개발생각] 미션 보상 기능을 코틀린 DSL 사용하면..

미션이 여러개 있고, 그 미션의 조건들에 따라 보상을 다양하게 주어야하는 보상시스템을 만들어야 한다고 했을때, 

가장 먼저 떠오르는방법은 전략패턴을 이용하여 각각의 미션 전략을 만들고, 그것들을 관리하고 동작하도록 하는 방법일것이다.

 

여기서 중요한 부분은 그 전략들을 선언할때, 인터페이스를 이용하여 구현을 하게 되는데,

이 인터페이스가 때로는, 코드를 읽거나 흐름을 파악하기가 어렵게 숨어서 동작하게 되는 케이스가 있다. 

로직이 복잡하여,

공통 로직을 수행하고, 여러 다양한 추가 로직을 수행하는것들이 더덕더덕 붙을때가 이런 경우중에 하나이다.

 

이렇게 좀더 흐름을 쉽게 이해하고 한눈에 보이게 하려면,

DSL을 구현하여 사용하면 좀더 깔끔하게 코드를 구성할수있다.

 

 

DSL의미가 도메인 특화 언어(문법)이기때문에,

도메인에 대한 흐름을 훨씬 잘 표현할수있게 구성할수있다.

 

rewardPolicy {
    whenEvent<UserRegistered> {
        ifCondition {
            isFirstRegistration()
            friendCount >= 3
        }

        giveReward {
            point(1000)
        }
    }
}

위와같이 코드를 표현할수있다.

 

이렇게 할수있는 이유가 lamda와 receiver등이 코틀린에서는 잘되어있기 때문이 아닐까 한다.

아래와 같이 DSL코드를 작성하면, 위와같이 DSL로 사용할수있다.

class RewardRuleBuilder<E : RewardEvent>(
    private val eventType: Class<E>
) {

    private val conditions =
        mutableListOf<(RewardConditionContext) -> Boolean>()

    private var reward: Reward? = null

    fun ifCondition(
        block: RewardConditionContext.() -> Unit
    ) {
        //조건 추가
    }

    fun giveReward(
        block: RewardBuilder.() -> Unit
    ) {
        reward = RewardBuilder()
            .apply(block)
            .build()
    }

    fun build(): RewardRule {
        return RewardRule(
            eventType = eventType,
            conditions = conditions,
            reward = reward
        )
    }
}

 

예전에 시나리오 베이스 챗봇 프로젝트를 코틀린으로 진행한적이 있었는데,

그때 시나리오의 작성을 DSL로 구현을 했던적이 있다.

뭐 대충 아래와 같이 동작하는 챗봇 DSL을 만들었었다.

scenario {

    Entry("A") {

         condition() {

         }

    } to Entry("B") {

        condition() {

         }

   }

}

DSL로 구현을 하면, 해당 흐름에 대해서, 동작의 흐름이 명확하게 표현이 된다.

그리고 여러 공통 로직이나, 여러 기능을 쉽게 녹일수가 있어서 유용하다.

그리고 DSL만 잘 관리하면, 유지보수 측면에서도 장점이 많다.

 

불행히, 이번 프로젝트에서는 적용을 하지 못했다... 

DSL을 만들기 위해서는 정책, 흐름이 명확히 끝난 상태여야 DSL제작이 가능하고, 효과가 있다.

흐름이 명확하지 않은 상태에서,

이후에 DSL의 흐름을 매번 변경하는 부분은 상당히 많은 코드를 건드리고 수정해야하는 부담이 되는 작업이기 때문이다.

 

interface 클래스의 default 함수를 통해, 해결을 하긴했는데,

DSL로 구성을 했으면,

좀더 확장성있고, 흐름을 쉽게 파악할수있는 코드로 구성할수가 있었는데... 좀 아쉽네 (그래도 나름 만족)

 

향후, 좀더 흐름과 정책이 명확해진 상태에서 한번 DSL을 도입해서, 수정을 해봐야겠다.