design-patterns

코드 품질 개선 기법 21편: 생성자를 두드려 보고 건너라 (새 탭에서 열림)

객체의 상태에 따라 특정 메서드 호출이 제한되는 설계는 런타임 에러를 유발하는 주요 원인이 됩니다. 개발자는 주석이나 문서에 의존하기보다, 언어의 문법적 특성을 활용해 '애초에 잘못 사용할 수 없는 구조'를 설계해야 합니다. 이를 위해 생성 시점에 초기화를 완료하거나, 지연 초기화 또는 상태를 분리한 타입을 활용해 객체의 안전성을 보장하는 것이 핵심입니다. **초기화 시점에 로직 실행과 팩토리 함수 활용** 객체를 생성하는 즉시 필요한 준비 작업을 마치는 방식입니다. * **생성자 및 init 블록 사용**: 모든 속성을 생성 시점에 결정하여 읽기 전용(`val`)으로 선언할 수 있어 객체의 불변성을 유지하기 좋습니다. * **생성자의 제약 사항**: 생성자 내에서는 `suspend` 함수 호출이 불가능하며, 복잡한 로직이나 부작용이 큰 코드를 작성할 경우 초기화되지 않은 속성에 접근하는 버그가 발생할 수 있습니다. * **정적 팩토리 함수**: 생성자를 `private`으로 숨기고 별도의 `createInstance` 같은 함수를 제공하면, 복잡한 준비 로직을 안전하게 처리한 뒤 완전한 상태의 인스턴스만 반환할 수 있습니다. **호출 시점에 실행되는 지연 초기화** 준비 작업의 비용이 크지만 실제로 사용되지 않을 가능성이 있을 때 유용한 방식입니다. * **최초 접근 시 실행**: 메서드 내부에서 준비 상태를 확인하고, 필요한 경우에만 로직을 실행하여 리소스를 효율적으로 관리합니다. * **Kotlin의 lazy 위임**: 수동으로 상태 체크 코드를 작성하는 대신 `by lazy`를 활용하면, 스레드 안전성을 확보하면서도 코드를 더 깔끔하게 유지할 수 있습니다. * **가변성 제어**: 수동 구현 시 속성을 가변(`var`)으로 선언해야 하는 단점이 있지만, `lazy`를 사용하면 이를 완화할 수 있습니다. **정적 타입을 활용한 상태 분리** 준비 전과 후의 상태를 별개의 클래스로 정의하여 컴파일 단계에서 오류를 방지하는 방식입니다. * **타입에 따른 권한 부여**: 준비 전 클래스에는 `prepare()`만 정의하고, 이 함수가 준비 완료된 새로운 타입의 객체를 반환하게 하여 `play()`와 같은 핵심 기능을 준비된 객체만 가질 수 있도록 제한합니다. * **컴파일 타임 안전성**: 호출자가 준비 과정을 거치지 않으면 기능을 아예 호출할 수 없으므로, 런타임 예외 발생 가능성을 원천적으로 차단합니다. * **세밀한 제어**: 호출자가 준비 시점을 직접 결정해야 하거나, 준비된 상태의 인스턴스를 캐싱하여 재사용해야 할 때 특히 효과적입니다. **실용적인 제언** 가장 좋은 설계는 사용자에게 주의를 요구하는 대신, 구조적으로 실수를 방지하는 설계입니다. 초기화 비용이 낮다면 생성자나 팩토리 함수를 통한 **즉시 초기화**를 권장하며, 실행 시점을 제어해야 하거나 안전성을 극대화해야 한다면 **상태별 클래스 분리**를 검토하는 것이 좋습니다.

코드 품질 개선 기법 17편: 사상누각 (새 탭에서 열림)

무분별한 빌더 패턴의 사용은 필수 인자의 누락을 런타임 시점에야 발견하게 만들어 코드의 안정성을 해칠 수 있습니다. 견고한 소프트웨어를 구축하기 위해서는 런타임 에러 대신 컴파일 타임에 결함을 발견할 수 있는 생성자나 팩토리 함수를 우선적으로 고려해야 합니다. 특별한 제약 사항이 있는 경우가 아니라면, 프로그래밍 언어의 기능을 활용해 불완전한 객체 생성을 원천 차단하는 것이 코드 품질 개선의 핵심입니다. **빌더 패턴의 한계와 위험성** * 전통적인 빌더 패턴은 필수 인자가 누락되어도 컴파일 단계에서 이를 감지하지 못하며, `build()` 호출 시점에 `IllegalStateException` 등의 런타임 에러를 발생시킨다. * 이는 '사상누각'처럼 기초가 불안정한 코드를 양산하는 결과를 초래하므로, 컴파일러가 인자 누락을 체크할 수 있는 생성자 기반 설계를 지향해야 한다. **기본값이 있는 인자가 많은 경우의 대안** * Kotlin과 같이 기본 인수를 지원하는 언어에서는 빌더 대신 생성자에 기본값을 설정함으로써 인자 전달의 유연성을 확보하고 가독성을 높일 수 있다. * 만약 환경상 빌더 패턴을 반드시 사용해야 한다면, 필수 인자만큼은 빌더의 생성자 인수로 직접 전달받도록 설계하여 누락 가능성을 구조적으로 방지한다. **생성 중인 상태의 처리와 타입 구분** * 빌더 객체를 다른 함수에 인자로 전달해 값을 채우는 방식(출력 인수)은 가독성을 떨어뜨리므로, 값을 반환받아 생성자나 팩토리 함수에 전달하는 방식으로 개선하는 것이 바람직하다. * 객체 생성 로직이 복잡한 파이프라인 형태라면 각 단계마다 서로 다른 타입을 정의함으로써, 유효하지 않은 중간 상태의 객체가 사용되는 것을 방지할 수 있다. **빌더 패턴이 효과적인 상황: 마지막 작업 정의** * 0회 이상 임의의 순서로 적용되는 작업이 있고, 특정 '마지막 작업(terminal operation)'을 통해 최종 결과를 산출해야 하는 경우에는 빌더 패턴과 유사한 구조가 유용하다. * 예를 들어 이미지 편집 과정(crop, filter 등)에서 데코레이터 패턴을 사용할 때, 빌더 형식을 도입하면 순수 데코레이터 패턴보다 중첩 구조가 단순해져 가독성이 크게 향상된다. 객체 생성 시 발생할 수 있는 결함을 런타임이 아닌 컴파일 타임에 검출할 수 있도록, 가장 먼저 생성자나 팩토리 함수 사용을 검토하세요. 빌더 패턴은 언어적 제약이 있거나 특수한 파이프라인 설계가 필요한 경우에만 선택적으로 활용하는 것이 좋습니다.

코드 품질 개선 기법 16편: 불이 'null'인 굴뚝에 연기가 'null'이 아닐 수 없다 (새 탭에서 열림)

널 객체(null object) 패턴은 `null` 대신 '비어 있음'을 나타내는 객체를 사용하여 호출부의 코드를 단순화하고 예외 처리를 줄이는 유용한 디자인 패턴입니다. 그러나 일반적인 상태와 오류 상태를 명확히 구분해야 하는 상황에서 이 패턴을 무분별하게 사용하면, 컴파일러의 정적 검증을 우회하게 되어 오히려 버그를 발견하기 어렵게 만듭니다. 따라서 오류 처리가 필수적인 로직에서는 널 객체 대신 언어 차원의 `null`이나 `Optional` 타입을 사용하여 타입 안정성을 확보하는 것이 권장됩니다. ### 널 객체 패턴의 활용과 장점 널 객체 패턴은 유효하지 않은 값이나 비어 있는 상태를 특정 객체로 정의하여 프로그램의 흐름을 끊지 않도록 돕습니다. - **코드 단순화**: 컬렉션의 경우 `null` 대신 빈 리스트(`.orEmpty()`)를 반환하면 호출 측에서 별도의 널 체크 없이 즉시 순회(iteration) 로직을 수행할 수 있습니다. - **폴백 데이터 제공**: UI 표시를 위한 데이터 모델에서 '알 수 없는 사용자'와 같은 기본 객체를 정의하면, 데이터가 없는 경우에도 화면 레이아웃을 깨뜨리지 않고 기본 정보를 안전하게 보여줄 수 있습니다. - **로직 통합**: 경계 조건이나 오류 상황을 일반적인 비즈니스 로직에 자연스럽게 통합시켜 코드의 가독성을 높입니다. ### 널 객체 패턴이 유발하는 타입 안정성 문제 오류 상태를 일반 객체처럼 취급하게 되면 개발자가 의도적으로 해당 상태를 확인해야 하는 로직을 누락했을 때 이를 잡아낼 방법이 부족해집니다. - **컴파일 타임 검증 부재**: `isInvalid`와 같은 속성으로 오류를 확인해야 하는 널 객체를 사용하면, 확인 로직을 잊더라도 컴파일러는 이를 정상적인 코드로 인식합니다. - **런타임 버그 발생**: 유효하지 않은 널 객체가 시스템 내부에서 계속 전달되다가 예상치 못한 지점에서 오작동을 일으킬 수 있으며, 이는 즉시 런타임 오류가 발생하는 것보다 원인 파악이 더 어렵습니다. - **대안으로서의 정적 타입**: Kotlin의 널 가능 타입(`?`)이나 Swift의 `Optional`을 사용하면 컴파일러가 강제로 널 처리를 요구하므로, 오류 조건과 일반 조건을 명확히 분리하여 처리할 수 있습니다. ### 널 객체 패턴 사용 시 주의할 점: 동일성과 동등성 널 객체를 정의하고 비교할 때는 객체의 비교 방식에 각별히 유의해야 합니다. - **동일성(Identity) 문제**: `UserModel.INVALID`와 같은 정적 인스턴스를 `==` 연산자로 비교할 때, 해당 클래스에 `equals`가 적절히 구현되어 있지 않으면 내용이 같더라도 다른 객체로 판별될 위험이 있습니다. - **값 기반 비교의 한계**: 단순히 기본값(ID 0, 빈 문자열 등)을 채워 넣은 새 객체를 생성해 비교할 경우, 실제 '무효한 상태'를 나타내는 싱글톤 객체와 일치하지 않아 로직 오류가 발생할 수 있습니다. ### 상황에 맞는 도구 선택 제안 널 객체 패턴은 만능 해결책이 아니며, 상황에 따라 적절한 도구를 선택하는 것이 중요합니다. - **널 객체를 권장하는 경우**: 일반적인 경우와 오류/경계 상황을 굳이 구분할 필요가 없거나, '오류'를 나타내는 후보가 너무 많아 정적 검증이 오히려 복잡해질 때 사용합니다. - **정적 타입을 권장하는 경우**: 비즈니스 로직상 오류 상태를 반드시 인지하고 별도의 처리(예: 에러 다이얼로그 표시)를 수행해야 한다면 널 객체 대신 언어에서 제공하는 `null`이나 `Optional`을 활용하여 타입 시스템의 보호를 받아야 합니다.