[Kotlin] 11장. DSL 만들기
11.1 API에서 DSL(Domain-Specific Language)로
개발자의 최종 목표는 코드의 가독성과 유지 보수성을 가장 좋게 유지하는 것이다. 이 목표를 달성하기 위해선 개별 클래스에 집중하는 것만으로는 충분치 않다. 클래스에 있는 코드 중 대부분은 다른 클래스와 상호작용한다. 그런 상호작용이 일어나는 연결 지점을 살펴봐야 한다.( =클래스의 API를 살펴봐야 한다.)
API가 깔끔하다는 뜻
- 코드를 읽는 독자들이 어떤 일이 벌어질지 명확하게 이해할 수 있어야 한다.
- 코드가 간결해야 한다.
StringUtil.capitalize(s) -> s.capitalize() : 확장함수
1.to("one") -> 1 to "one" : 중위 호출
set.add(2) -> set += 2 : 연산자 오버로딩
map.get("key") -> map["key"] : get 메소드에 대한 관례
file.use({ f -> f.read() }) -> file.use{ it.read() } : 람다를 괄호 밖으로
sb.append("yes") -> with(sb){append("yes") : 수신 객체 지정 람다
sb.append("no") append("no")} 코틀린 언어의 다른 특성과 마찬가지로 코틀린 DSL도 온전히 컴파일 시점에 타입이 정해진다. 따라서 컴파일 시점 오류 감지, IDE 지원 등 모든 정적 타입 지정 언어의 장점을 코틀린 DSL을 사용할 때도 누릴 수 있다.
11.1.1 영역 특화 언어라는 개념
우리는 컴퓨터가 발명된 초기부터 컴퓨터로 풀 수 잇는 모든 문제를 충분히 풀 수 있는 기능을 제공하는 범용 프로그래밍 언어(General-purpose programming language) 와 특정 과업 또는 영역에 필요하지 않은 기능을 없앤 영역 특화 언어를 구분해왔다. (ex. SQL과 정규식)
DSL이 범용 프로그래밍 언어와 달리 더 선언적이다. 범용 프로그래밍 언어는 모통 명령적이다. 명령적 언어는 어떤 연산을 완수하기 위해 필요한 각 단계를 순서대로 정확히 기술하는 반면, 선언적 언어를 원하는 결과를 기술하기만 하고 그 결과를 달성하기 위해 필요한 세부 실행은 언어를 해석하는 엔진에 맡긴다. 실행 엔진이 결과를 얻는 과정을 전체적으로 한꺼번에 최적하기 때문에 선언적 언어가 더 효율적인 경우가 자주 있다. 단점이 있는데 DSL을 범용 언어로 만든 호스트 애플리케이션과 함께 조합하기 어렵다는 점이다. 이를 보완한 것이 내부 DSL 이다.
11.1.2 내부 DSL
내부 DSL은 범용 언어로 작성된 프로그램의 일부며, 범용 언어와 동일한 문법을 사용한다. 따라서 내부 DSL은 완전히 다른 언어가 아니라 DSL의 핵심 장점을 유지하면서 주 언어를 특별한 방법으로 사용하는 것이다. (예: QueryDSL)
11.1.3 DSL의 구조
다른 API에는 존재하지 않지만 DSL에만 존재하는 특징이 한 가지 있다. 바로 구조 또는 문법이다. DSL의 메소드 호출은 DSL 문법에 의해 정해지는 커다란 구조에 속한다. 코틀린 DSL에서는 보통 람다를 중첩시키거나 메소드 호출을 연쇄시키는 방식으로 구조를 만든다.
11.2 구조화된 API 구축: DSL에서 수신 객체 지정 DSL 사용
11.2.1 수신 객체 지정 람다와 확장 함수 타입
fun buildString{
// 수신 객체가 있는 함수 타입의 파라미터를 선언한다.
builderAction: StringBuilder.() -> Unit
): String{
val sb = StringBuilder()
sb.builderAction() // StringBuilder 인스턴스를 람다의 수신객체로 넘긴다.
return sb.toString()
}
fun main() {
val s = buildString {
this.append("hello, ")
append("World!")
}
println(s)
}위 예제코드에서 파라미터 타입을 선언할 때 일반 함수 타입 대신 확장 함수 타입을 사용했다. 확장 함수 타입 선언은 람다의 파라미터 목록에 있던 수신 객체 타입을 파라미터 목록을 여는 괄호 앞으로 빼 높으면서 중간에 마침표(.)를 붙인 형태다.
일반 람다를 사용할 때는 StringBuilder 인스턴스를 builderAction(sb) 구문을 사용해 전달하지만 수신 객체 지정 람다를 사용할 때는 sb.builderAction() 으로 전달한다. 다시 말해 sb.builerAction() 에서 builderAction 은 StringBuilder 클래스 안에 정의되어 있는 함수가 아니며, StringBuilder 인스턴스인 sb는 확장 함수를 호출할 때와 동일한 구문으로 호출할 수 있는 함수 타입의 인자일 뿐이다.
11.3 invoke 관례를 사용한 더 유연한 블록 중첩
invoke 관례를 사용하면 함수처럼 호출할 수 있는 객체를 만드는 클래스를 정의할 수 있다.
11.3.1 invoke 관례: 함수처럼 호출할 수 있는 객체
class Greeter(val greeting: String){
operator fun invoke(name: String){
println("$greeting, $name")
}
}
fun main() {
val bavarianGreeter = Greeter("Servus")
println(bavarianGreeter("Dimitry"))
}이 코드는 Greeter 안에 invoke 메소드를 정의한다. 따라서 Greeter 인스턴스를 함수처럼 호출할 수 있다. bavarianGreeter(“Dimitry”) 는 내부적으로 bavarianGreeter.invoke(“Dimitry”)로 컴파일된다. 신기한 것이 따로 있는 것이 아니고 미리 정해둔 이름을 사용한 메소드를 통해 긴 식 대신 더 짧고 간결한 식을 쓸 수 있게 해준다.
11.3.2 invoke 관례와 함수형 타입
data class Issue(
val id:String, val project: String, val type: String,
val priority: String, val description: String
)
class ImportantIssuesPredicate(val project: String): (Issue) -> Boolean{
override fun invoke(issue: Issue): Boolean {
return issue.project == project && issue.isImportant()
}
private fun Issue.isImportant(): Boolean{
return type == "Bug" &&
(priority == "Major" || priority == "Critical")
}
}
fun main() {
val i1 = Issue("IDEA-154446", "IDEA", "Bug", "Major", "Save settings failed")
val i2 = Issue("IDEA-12183", "Kotlin", "Feature", "Normal", "Intention: Convert several calls on the same receiver to with/apply")
val predicate = ImportantIssuesPredicate("IDEA")
for(issue in listOf(i1, i2).filter(predicate)){
println(issue.id)
}
}람다를 함수 타입 인터페이스를 구현하는 클래스로 변환하고 그 클래스의 invoke 메소드를 오버라이드하면 람다를 여러 메소드로 나누고 각 메소드에 이름을 붙일 수 있다.
