<div id="readability-page-1" class="page"><article><div><blockquote>이 글은 2024년 3월 7일에 일본어로 먼저 발행된 기사를 번역한 글입니다.</blockquote>
<p>안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다.</p>
<p>저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.</p>
<p>Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. <span>이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 <a href="https://techblog.lycorp.co.jp/ko/techniques-for-improving-code-quality-list" target="_blank">코드 품질 개선 기법 시리즈</a>를 연재하고 있습니다.</span></p>
<p><span>이번에 블로그로 공유할 Weekly Report의 제목은 '불이 'null'인 굴뚝에 연기가 'null'이 아닐 수 없다'입니다.</span></p>

<p><a href="https://en.wikipedia.org/wiki/Null_object_pattern" target="_blank">널 객체(null object) 패턴</a>은 <code>null</code>, <code>nil</code>, <code>undefined</code>와 같은 값 대신 '비어 있음'이나 '유효하지 않음'과 같은 의미를 가진 객체를 사용하는 디자인 패턴 중 하나입니다. 이 패턴을 사용하는 이유로는 몇 가지가 있는데요. 대표적인 이유 중 하나는 ‘오류를 폴백(fallback)용 값으로 변환’하기 위해서 입니다.</p>
<p><code>TeamDao.selectMemberIds(TeamId): List&lt;Int&gt;?</code>라는 함수가 있다고 가정해 봅시다. 이 함수는 보통 팀 멤버의 ID 목록을 반환하지만 존재하지 않는 팀 ID가 입력되면 <code>null</code>을 반환합니다. 다음 <code>TeamModelRepository.getMemberIds(TeamId)</code>에서는 <code>TeamDao.selectMemberIds</code>가 <code>null</code>을 반환하면 <code>.orEmpty()</code>를 사용해 빈 목록으로 폴백합니다.</p>
<pre><code>class TeamModelRepository(private val dao: TeamDao) {
    fun getMemberIds(teamId: TeamId): List&lt;Int&gt; =
        dao.selectMemberIds(teamId).orEmpty()
}</code></pre>
<p>이 패턴을 적절히 사용하면 호출자의 코드를 단순하게 만들 수 있습니다. 대표적인 예로 <code>List</code>와 같은 컬렉션을 순회하는 것을 들 수 있습니다. 다음 코드는 앞서 언급한 <code>TeamModelRepository.getMemberIds</code>를 호출하는데요. <code>null</code>을 처리할 필요가 없기 때문에 코드가 단순해졌습니다.</p>
<pre><code>teamModelRepository.getMemberIds(teamId).asSequence()
    .map(userModelRepository::getUserModel)
    .map(UserModel::getName)
    .forEach { userName -&gt; sendMessage("Hello, $userName") }</code></pre>
<p>널 객체 패턴은 <code>List</code>와 같은 일반화된 타입뿐 아니라 애플리케이션 고유의 데이터 모델에도 사용할 수 있습니다. 다음 <code>UserModel</code>은 <code>INVALID</code>라는 인스턴스를 널 객체로 정의합니다.</p>
<pre><code>class UserModel(
    val id: Int,
    val accountName: String,
    val nickName: String,
    val emailAddress: String
) {
    val isInvalid: Boolean
        get() = this == INVALID

    companion object {
        val INVALID = UserModel(0, "", "", "")
    }
}</code></pre>
<p>이 <code>UserModel</code>은 다음과 같이 사용합니다.</p>
<pre><code>class UserModelRepository(private val dao: UserDao) {
    fun getUserModel(userId: Int): UserModel =
        dao.selectUser(userId) ?: UserModel.INVALID
}

// On the caller side
fun caller(userId: Int) {
    val userModel = userModelRepository.getUserModel(userId)

    if (userModel.isInvalid) {
        ... // Unhappy-path logic such as showing a dialog
        return
    }

    ...
    // Happy-path logic, such as updating profile UI
}</code></pre>
<p>이 코드에 문제가 있을까요?</p>
<h3 id="null에-연기가-나지-않게-하기">`null`에 연기가 나지 않게 하기</h3>
<p>널 객체와 일반 객체를 구분해야 하는 경우 널 객체 패턴을 사용하지 않는 것이 코드를 더 견고하게 만들 수 있습니다.</p>
<p>이를 이해하려면 먼저 널 객체 패턴의 장점을 확인해야 하는데요. 널 객체 패턴의 장점 중 하나는 경계 조건이나 오류 조건의 로직을 일반적인 경우의 로직에 쉽게 통합할 수 있다는 것입니다. 다음 코드가 그 예시입니다.</p>
<pre><code>class ProfileViewData(
    val userName: String,
    val profileImagePath: Path,
    ...
) {
    companion object {
        private val UNKNOWN = ProfileViewData("Unknown user", UNKNOWN_USER_IMAGE_PATH, ...)

        fun fromProfileModel(model: ProfileModel?) {
            if (model == null) {
                return UNKNOWN // Converts null to a null object
            }

            // Happy-path case
            ...
            return ProfileViewData(...)
        }
    }
}

// On the caller side
fun updateProfileView(val profileModel: ProfileModel?) {
    val viewData = ProfileViewData.fromProfileModel(profileModel)

    // Only happy-path case, no unhappy-path case
    nameTextView.text = viewData.userName
    profileImageView.image = loadImage(viewData.profileImagePath)
    ...
}</code></pre>
<p>반대로 경계 조건이나 오류 조건을 일반적인 경우와 분리해야 할 때에는 널 객체 패턴을 사용하기에 적절하지 않은 경우가 많습니다. 예를 들어 위 <code>UserModel</code>의 코드 스니펫에서는 <code>userModel.isInvalid</code>를 확인해야 하는데요. 만약 <code>isInvalid</code>를 확인하는 것을 잊어버려도 컴파일을 통과하기 때문에 실제로 작동시켜 보지 않으면 버그를 발견할 수 없습니다.</p>
<p>경계 조건 및 오류 조건과 일반 조건을 명확하게 구분해야 할 때에는 정적으로 검증되는 타입을 사용하는 것이 더 바람직합니다. 대표적으로 Kotlin의 <code>null</code>, Swift의 <code>nil</code>, 다른 언어의 <code>Optional</code> 또는 <code>Maybe</code> 등이 있습니다. 다른 타입을 사용해 오류를 구분하는 것은 동적 타이핑을 사용하는 언어에서도 효과적입니다. 실행돼서는 안 되는 코드가 그대로 실행되는 것보다 런타임 오류가 발생하는 것이 버그를 더 쉽게 발견할 수 있기 때문입니다.</p>
<p>널 객체 패턴은 다음 중 한 가지 상황일 때에만 사용하는 것이 좋습니다.</p>
<ol><li>경계 조건 및 오류 조건의 경우와 일반적인 경우를 구분할 필요가 없다.</li><li>'오류'를 나타내는 값의 후보가 여러 개이고 그중 어떤 값을 사용할지 정적으로 검증할 수 없다.
<ul><li>예: <code>List&lt;T&gt;?</code>의 <code>null</code>과 빈 목록의 경우, <code>List&lt;T&gt;</code>로 변경하고 빈 목록만 오류 값으로 사용해야 하는 경우가 많다.</li></ul>
</li></ol>
<h3 id="참고-identity와-equivalence">참고: 동일성과 동등성</h3>
<p>‘동일성(identity)’는 ‘동일한 객체’를 의미하고 ‘동등성(equivalence)’는 ‘(비록 다른 객체더라도) 동일한 값'을 의미합니다. 널 객체 패턴을 사용할 때는 이 동일성과 동등성의 차이에 주의해야 합니다.&nbsp;</p>
<p>예를 들어 <code>UserModel.isInvalid</code>는 <code>... == INVALID</code>와 같은 방식으로 구현돼 있고, <code>UserModel</code>은 자체적인 <code>equals</code>가 구현돼 있지 않은데요. 이 경우 <code>UserModel(0, "", "", "").isInvalid</code>의 결과는 <code>false</code>가 돼 해당 동작이 예상치 못한 버그를 발생시킬 수 있습니다.</p>
<hr>
<blockquote>
<p>한 줄 요약: 오류 값을 구분해야 하는 경우에는 널 객체 패턴을 사용하지 않는 것이 좋다.</p>
<p>키워드: <code>error value</code>, <code>type safeness</code>, <code>null object pattern</code><a href="https://techblog.lycorp.co.jp/ko/code-review-series" target="_blank"></a></p>
</blockquote></div></article></div>

LINE ENGINEERING

이 글은 2024년 3월 7일에 일본어로 먼저 발행된 기사를 번역한 글입니다.안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회...

코드 품질 개선 기법 16편: 불이 'null'인 굴뚝에 연기가 'null'이 아닐 수 없다

댓글