TIL

아이템 27 변화로부터 코드를 보호하려면 추상화를 사용하라

• 추상화를 통해 사용자가 세부 사항을 알지 못해도 괜찮다는 장점이 있다.
• 추상화를 통해 변화로부터 코드를 보호하는 행위가 어떤 자유를 가져오는지 세 가지 사례를 통해 살펴보자.

상수

• 리터럴은 아무것도 설명하지 않기에 코드에 반복적으로 등장할 때마다 문제가 된다.

fun isPasswordValid(text: String): Boolean {
	if (text.length < 7) return false
	// ...
}

• 이를 상수로 추출한다면 쉽게 이해할 수 있고 변경하기도 쉽다.

const val MIN_PASSWORD_LENGTH = 7

fun isPasswordValid(text: String): Boolean {
	if (text.length < MIN_PASSWORD_LENGTH) return false
	// ...
}

함수

• 자주 사용하는 기능은 보통 함수로 만든다.

// 화면에 토스트 메시지를 출력하는 확장 함수
fun Context.toast(message: String, duration: Int = Toast.LENGTH_LONG) {
	Toast.makeText(this, message, duration).show()
}

• 만약 토스트가 아니라 스낵바라는 형태로 출력해야 한다고 요구사항이 변경되면 어떻게 변경할까?
• 함수 이름을 변경하고 내부 구현을 변경할 순 있지만 이는 추천하지 않는다.
  • 함수 이름을 직접 바꾸는 것은 위험할 수 있다.
  • 다른 모듈이 이 함수에 의존하고 있다면 큰 문제가 발생할 수 있다.
  • 함수 이름을 한 번에 바꾸는 건 쉽지만 파라미터는 한 번에 바꾸기 쉽지 않다.
• 메시지 출력 방식이 바뀐다면 중요한 것은 출력 방법이 아니라 메시지를 출력하고 싶다는 의도이다.

fun Context.showMessage( // 메시지를 출력한다는 추상적인 이름
	message: String, 
	duration: MessageLength = MessageLength.LONG),
) {
	// ...
}

• 함수는 추상화를 표현하는 수단이며 어떤 추상화를 표현하는지 시그니처가 알려주기에 의미 있는 이름은 굉장히 중요하다.
• 함수는 매우 단순한 추상화지만 제한이 많다.
  • 함수는 상태를 유지하지 않는다.
  • 함수 시그니처의 변경은 프로그램 전체에 큰 영향을 줄 수도 있다.

클래스

• 클래스는 함수보다 강력하다.
  • 상태를 가질 수 있다.
  • 많은 함수를 가질 수 있다.
  • 의존성 주입 프레임워크를 통해 클래스 생성을 위임할 수 있다.
  • mock 객체를 통해 테스트를 쉽게 진행할 수 있다.
• 클래스는 더 많은 자유를 가져다주지만 여전히 한계는 존재한다.
  • 클래스가 final이라면 해당 타입 아래 어떤 구현이 있는지 알 수 있다.
  • open 클래스를 통해 더 자유를 얻을 수 있는데 이는 서브 클래스를 제공할 수 있기 때문이다.
• 더 많은 자유를 위해선 인터페이스 뒤에 클래스를 숨기면 된다.

인터페이스

• 코틀린 표준 라이브러리를 보면 거의 모든 것이 인터페이스로 표현된다.
• 인터페이스를 통해 결합을 줄일 수 있다.
  • 사용자가 클래스를 직접 사용하지 못한다.
  • 라이브러리 개발자는 인터페이스만 유지한다면 내부 구현을 얼마든지 변경할 수 있다.
• 클래스가 아닌, 인터페이스를 리턴하는 데도 장점이 있다.
  • ex) 멀티 플랫폼 언어인 코틀린은 코틀린 JVM, 코틀린/JS 등에 따라 구현이 다른 리스트를 리턴하지만 인터페이스를 통해 이를 숨길 수 있다.
• 또한 테스트 시 페이크 객체를 통해 별도 모킹 라이브러리 없이도 대역 객체를 생성할 수 있다.

보편 객체를 특수 객체로 래핑

• 보편적인 타입(예: Int, String 등) 대신 도메인에 특화된 래퍼 객체로 감싸면, 의미를 명확히 하고 타입 안전성을 높일 수 있다.
• 이렇게 하면 잘못된 값의 혼용이나 실수를 컴파일 타임에 방지할 수 있다.
• 특수 객체로 래핑하면 코드의 의도와 역할이 분명해지고, 유지보수와 확장에도 유리하다.
• 즉, 도메인 개념을 코드로 명확히 표현하려면 보편적 객체 대신 특수 객체로 감싸는 것이 좋다.

data class Id(private val id): Int

추상화의 문제

• 추상화를 하려면 해당 개념을 잘 배우고 이해해야 한다.
• 프로젝트에 따라 극단적으로 모든 것을 추상화하면 득보다 실이 많아질 수 있다.
• 추상화는 많은 것을 숨길 수 있는 테크닉이다.
  • 개발이 쉬워지는 것도 사실이지만 이해하는 것 자체가 어려워진다.
• 추상화를 이해하려면 예제를 살펴보는 것이 좋다.
  • 단위 테스트와 문서 등은 추상화의 사용 방식을 확실히 보여준다.

균형 맞추기

• 추상화의 균형을 맞추기 위해 고려해야 할 것들
  • 팀의 크기
  • 팀의 경험
  • 프로젝트 크기
  • 특징 세트
  • 도메인 지식
• 적용할 수 있는 몇 가지 규칙
  • 많은 개발자가 참여하는 프로젝트는 변경에 대비해 추상화를 활용하는 것이 좋다.
  • 의존성 주입 프레임워크를 통해 객체 생성의 복잡도는 신경쓰지 않아도 된다.
  • 테스트를 하거나 다른 애플리케이션 기반의 새로운 애플리케이션을 만든다면 추상화를 사용하는 것이 좋다.
  • 프로젝트가 작고 실험적이라면 추상화를 하지 않아도 된다.