Step2

https://github.com/next-step/kotlin-lotto/pull/759

검증부는 하드 코딩을 사용하자

테스트코드에서 검증을 위해 도메인의 상수를 그대로 사용해 검증 로직을 짰는데 테스트에서는 상수를 직접 활용하기 보다는 하드 코딩을 해보는건 어떻겠냐는 피드백을 받았다.

검증부에 도메인 로직을 추가했을 때의 문제점은 다음과 같다.

무의미한 검증
- 사실상 프로덕션 코드를 복사 & 붙여넣기 한 것과 같다.
구현 코드와의 강결합
- 프로덕션 코드와 강결합하게 되면 결과는 동일하지만 로직이 변경되는 리팩터링을 한다면 테스트 코드의 도메인 로직 또한 함께 고쳐야 한다.
거짓 성공
- 도메인 로직 자체가 버그인 경우에도 테스트 코드가 실패하지 않는다.
- 즉, 검증문에 동일한 로직을 사용하는 순간 내 도메인 로직은 검증을 보장받지 못하게 된다.
Test First(TDD)의 어려움
- 소프트코드를 작성한다는 것 자체가 나는 Test First로 개발하지 않는다는 것을 의미한다. Test First 자체가 구현부를 미리 생각하고 진행하는 것이 아니라, 예상 결과를 미리 테스트 코드로 구현후 구현부를 만들고 리팩토링 하는 과정으로 진행한다.
- 그렇기 때문에 이미 구현부를 테스트 코드에서 선작성하는 것은 리팩토링 과정을 포기하는 것과 다를바 없다.
결과 예측의 어려움
- 예상되는 테스트코드의 결과를 한눈에 파악하기 어렵다.
- 다음과 같이 expected 가 선언된 경우 결과가 예상이 될까?

string expected = "C:\\\\Output Folder" + string.Join("\\\\", target.Field1, target.Field2, target.Field3, target.Field4);

참고

https://jojoldu.tistory.com/615?category=1036934

Step3

https://github.com/next-step/kotlin-lotto/pull/769

일급 컬렉션 내부 값 처리하기

일급 컬렉션을 만들 경우 가독성이 향상되며 유효성 검증을 세부적으로 할 수 있고 불변한 객체를 만들 수 있다는 장점이 있다.
이러한 이유로 일급 컬렉션을 적용하는데 내부 값에 대한 처리가 필요할 때 외부 클래스에서는 값을 꺼내서 처리해야 하기 때문에 값을 꺼내서 처리하는 부분에서 코드가 조금 더러워지는 것을 느꼈다.
내부 값에 대한 처리가 필요한 경우에는 외부에서 값을 꺼내기보다 일급 컬렉션 클래스 내에서 처리하는 것까지가 일급 컬렉션의 역할이며 역할도 깔끔하게 분리할 수 있는 방법이다.

class LottoMatcher(private val winningNumbers: List<Int>) {

    fun getMatchingResult(lottoTickets: LottoTickets): LottoResult {
        val map = lottoTickets.numbers
            .map { numbers -> countMatchingNumbers(numbers) }
            .groupingBy { LottoRank.getLottoRankByMatchCount(it) }
            .eachCount()
        return LottoResult(map)
    }

    private fun countMatchingNumbers(myNumbers: Numbers) = myNumbers.values.count { winningNumbers.contains(it) }
}

class WinningTicket(private val winningNumbers: LottoNumbers) {

    fun getMatchingResult(lottoTickets: LottoTickets): LottoResult {
        return myTickets
            .matchCount(winningNumbers)
            .groupingBy { matchCount -> LottoRank(matchCount) }
            .eachCount()
            .let { LottoResult(it) }
    }
}

아래와 같이 일치하는 로또 개수를 계산하는 로직을 LottoTickets 일급 컬렉션에 위임하면서 코드가 깔끔해지고 가독성을 높일 수 있었다.

value class 사용하기 (메모리 절약하기)

자주 사용되며, 고정되어 만들어지는 객체들에 대해서는 미리 만들어두고 재활용하는 방법을 사용하면 좋다.

@JvmInline
value class LottoNumber(
    val number: Int
) {
    init {
        require(number in (MIN..MAX)) {
            "$MIN 과 $MAX 사이의 값만 생성할 수 있습니다. input: [$number]"
        }
    }

    companion object {
        private const val MIN = 1
        private const val MAX = 45
    }
}

위의 LottoNumber 클래스를 디컴파일해보면 생성자에서 int 타입을 리턴하고 있는 것을 볼 수 있을 것이다.

검증이 가능한 안정적인 객체를 위해 원시값을 래핑하다보니 인스턴스를 만들어 힙 메모리를 차지하게 되고 이를 줄여주기 위해 로컬 캐시를 사용했었는데 value class를 만들면 인스턴스 자체를 만들지 않을 수 있다.

즉, value class 를 통해 원시값 포장으로 인해 생성되는 인스턴스로 인한 힙 메모리를 절약할 수 있다.

단, value class 는 하나의 값(프로퍼티)만 가질 수 있다.
- 2개 이상의 값을 가져야 한다면 캐싱 및 팩토리함수를 사용한다.
불변 객체를 만들어 메모리를 차지하는 것이 불안하다 → 메모리보다 내가 안전하게 코딩할 수 있다는 가치가 더 크다. (항상 해왔던 고민인데 이에 대한 명쾌한 답인 것 같다.)

Step4

https://github.com/next-step/kotlin-lotto/pull/789

리턴 타입을 명시하자

리턴 타입을 명시하는 것에 대한 리뷰를 받았다. 코틀린은 타입 추론이 가능한 언어다. 따라서 함수의 리턴 타입을 생략하기 쉬운 환경이라 이를 간과하기 쉽다.
예를 들어 인터페이스 타입을 명시적으로 지정해주고 하위 타입으로 초기화한 객체가 있을 경우 명시적으로 지정해준 타입을 지워버리면 하위 타입의 객체만 사용이 가능해지는 문제를 겪을 수 있다.
리턴 타입은 API를 잘 모르는 다른 개발자가 볼 때 아주 중요한 정보이다. 따라서 리턴 타입은 외부에서 확인할 수 있게 명시적으로 지정해주는 것이 좋다.

View 의 도메인 의존

View에서 출력할 도메인 정보가 강하게 결합되어 있어 View에서 도메인 로직을 가져가는 구조로 구현을 하였다. 이에 대한 고민이 있었지만 현재와 같이 간단한 미션과 구조를 가진 상황에서 DTO까지는 굳이 만들어주지 않았다.

View에서 도메인 로직을 가지고 있는 것이 아닌 도메인의 값을 꺼내서 출력만 하는 경우이기 때문에 허용해도 괜찮지 않을까 생각한다는 리뷰어님의 답변을 받았다.

하지만 도메인이 커지고 규모가 커진다면 View에서는 도메인 보호를 위해 Dto를 가지고 있는 것이 더 좋은 방법이다.