[Effective Kotlin] entity class에서 Id를 선언할 때, 생성자의 파라미터 순서 상 가장 밑으로 두는 것이 좋은 이유

🔍  우선, 코틀린에서 Entity Class 생성자에 매개변수를 선언할 때, id를 맨 위에 선언했을 경우로 예를 들어보겠습니다.

생성자 호출시, 네임드 파라미터를 사용하지 않았을 때

@Entity
class User(

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val email: String,

    @Column(nullable = false)
    val password: String,

) {
    fun user() = User("email@tistory.com", "password")
}

위와 같은 코드는 파라미터 순서가 맞지 않기 때문에 컴파일 에러가 발생하게 됩니다.

 

위 문제는 코틀린에서 지원해주는 네임드 파라미터를 사용함으로써 아래와 같이 해결할 수 있습니다.

@Entity
class User(

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val email: String,

    @Column(nullable = false)
    val password: String

) {
    fun user() = User(email = "email@tistory.com", password = "password")
}

네임드 파라미터를 사용하면 생성자 호출시 

fun user() = User(password = "password", email = "email@tistory.com")

파라미터의 순서가 바뀌어도 상관이 없습니다. 이것은 또한 자바와 다르게 코틀린에서 굳이 빌더를 사용할 필요가 없는 이유이기도 하죠.

 

코틀린에서는 롬복대신 data class를 사용하면 빌더를 사용할 필요가 없기 때문에 자바에 비해 간결한 코드를 작성할 수 있습니다. 이것은 자바에 비해서 코틀린이라는 언어의 장점 중에 하나이기도 하죠.

 

코틀린에서 네임드 파라미터란, 

 

파라미터에 의미를 문서화한다는 것으로 위의 사진과 같이 좌측에 있는 email, password를 네임드 파라미터라고 부를 수 있습니다.

 

여기까진 보통 코틀린 + 스프링으로 프로젝트를 해보신 분이라면, 어느정도 아시는 내용이실 겁니다. 중요한 내용은 아래부터 입니다.

🔍  코틀린에서 Entity Class 생성자에 매개변수를 선언할 때, id를 맨 아래에 선언했을 경우

보통 Entity class에 매개변수를 선언할 때, id를 맨 위에 선언하시는 분이 많습니다. 맨 위에 선언하는 명확한 이유가 있거나, 오픈소스나 블로그에서 보통 맨 위에 선언되어 있는 코드들이 많아 관례적으로 맨 위에 선언하거나..

 

하지만 코틀린 + 스프링에서는 맨 위보다는 맨 아래에 선언하는 것이 네임드 파라미터를 사용하지 않을 경우의 장점 및  네임드 파라미터를 사용할 필요가 없는 경우에 다른 개발자분들을 배려하는 코드를 작성할 수 있는 장점이 있다고 생각해서 이 글을 작성해 보았습니다.

 

id를 맨 아래에 선언했을 경우에는

@Entity
class User(

    @Column(nullable = false)
    val email: String,

    @Column(nullable = false)
    val password: String,

    // 위의 에제와 다르게 맨 아래 선언
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L

) {
    fun user() = User("email@tistory.com", "password")
}

id를 맨 위에 선언했던 위의 예제와 다르게 컴파일 오류가 발생하지 않습니다. id가 맨 뒤에 선언이 되었기 때문에 위의 코드에서 파라미터 순서가 불일치 되는 경우가 발생하지 않기 때문이죠.

 

스프링으로 프로젝트를 하다보면 id를 생략하는 경우가 참 많죠. 이럴때 id를 생략하더라도 굳이 네임드 파라미터를 쓰지 않아도 되는 장점이 있습니다. 

 

물론 id가 맨 위에 선언되든 맨 아래 선언되든 네임드 파라미터를 사용하면 순서는 상관 없기 때문에 상관없긴 합니다.

 

하지만, 네임드 파라미터를 쓰든 안쓰든 맨 위보다는 사전에 맨 아래에 작성하는게 낫다고 생각합니다.  이는 협업시, 네임드 파라미터를 사용할 필요가 없는 경우에 다른개발자분들을 위해 배려하는 코드를 작성할 수도 있기 때문이죠.(id를 생략하더라도 굳이 네임드 파라미터를 쓰지 않아도 되기 때문에)

 

물론, 네임드 파라미터를 사용한다고 해도 맨 아래 id를 선언해서 문제될 점도 없구요.

 

사소할수도 있지만, 이렇게 다른 개발자를 배려하기 위한 코드를 작성하는 것도 협업시 개발자가 꼭 갖춰야할 능력이라고 생각합니다.

🔍  그럼 네임드 파라미터를 사용하는게 좋을까요, 사용하지 않는 것이 좋을까요?

네임드 파라미터를 사용했을 때의 장점은

User("email@tistory.com", "password") 
// 네임드 파라미터를 사용하지 않았을때의 비해

User(password = "password",email = "email@tistory.com") 
// 네임드 파라미터를 사용하면 가독성 향상

User(email = "email@tistory.com", password =  "password")
// 및 파라미터 순서에 구애받지 않음

아무래도 순서를 굳이 맞춰주지 않거나 가독성 면에서 장점이 있습니다. 2개 이상의 같은 타입이 사용되는 경우에도 네임드 파라미터를 사용하는 것이 더 좋을 수 있습니다.

 

반대로 네임드 파라미터를 사용할때의 단점은 아무래도 코드가 길어지게 됩니다. 파라미터가 많을수록 더욱 길어지겠죠.

User("password","email@tistory.com")
// 네임드 파라미터를 사용하지 않았을때의 비해

User(email = "email@tistory.com", password = "password")
// 네임드 파라미터를 사용하면 코드가 길어짐.

fun user(userRequest: UserRequest) = User(email = "email@tistory.com", password = userRequest.password)
// userRequest.password 이름 자체가 직관적이기 때문에    

fun user(userRequest: UserRequest) = User(userRequest.email, userRequest.password)
// 굳이 네임드 파라미터를 사용할 필요가 없음

 

또한 이미 변수에 담겨 있는 값을 사용하는 경우 변수 이름으로도 전달이 되면 네임드 파라미터를 사용하지 않아도 충분히 코드는 읽기 쉬워집니다. 이 경우 네임드 파라미터를 사용하면 불필요하게 코드가 길어지겠죠.

 

저 같은 경우는 다른 개발자분들에게 혼란을 주지 않는 이상, 코드가 짧아지는 걸 지향하긴 합니다. 하지만 혼란을 줄 만큼 길어지면 네임드 파라미터를 사용하는 것을 지향하고 있죠.

 

물론 네임드 파라미터를 사용한다고 해서 꼭 가독성이 좋아지는 것만도 아닙니다. 너무 길어지면 읽기 어려운 코드가 될 수도 있죠. 이 경우에는 메서드에 너무 많은 파라미터가 주입되고 있는 것이 잘못된 설계가 아닌지 고민해보기도 합니다.

 

따라서, 상황에 따라 적절히 사용하는 것이 최선의 답이라고 생각합니다.

🔍  결론

코틀린 + 스프링 프로젝트에서 생성자의 파라미터 순서상 id를 가장 아래 선언했을 때의 장점은,

• id를 생략하더라도 굳이 네임드 파라미터를 쓰지 않아도 됩니다. -> 상황에 따라 조금더 간결한 코드를 작성할 수 있습니다.
• 네임드 파라미터를 사용할 필요가 없는 경우에 다른 개발자분들을 배려하는 코드를 작성할 수 있습니다. -> id를 생략하더라도 굳이 네임드 파라미터를 써야하는 비용이 감소하기 때문에