코틀린 디자인 패턴 (7) – Bridge 패턴은 상속 폭발을 어떻게 줄일까
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
코틀린 let, run, apply, also, with 차이를 this, it, 반환값 기준으로 쉽게 정리합니다. nullable 처리, 객체 설정, 부수 효과, 계산 결과라는 실전 장면에서 언제 무엇을 고르면 되는지 설명합니다.
코틀린에서 상태를 표현할 때 enum이 맞는지 sealed class가 맞는지 UI 상태 예제로 쉽게 정리합니다. payload, when 분기, enum이 더 단순한 순간까지 실무 기준으로 설명합니다.
Kotlin data class는 짧게 쓰기 편한 문법처럼 보이지만, 실제로는 equals, copy, componentN이 함께 움직이는 값 중심 설계 도구에 가깝습니다. 이 글에서는 query 객체, UI state, mutable list 예제로 data class가 어디까지 편하고 어디서부터 조심해야 하는지 실무 기준으로 정리합니다.
repeatOnLifecycle과 launchWhenStarted 차이를 안드로이드 Flow 수집 관점에서 정리합니다. 왜 repeatOnLifecycle이 더 안전한지, collector restart, lifecycle gap, duplicate collection, Fragment View UI 예제까지 실무적으로 설명합니다.
1편에서는 코틀린 클린코드의 기준을 잡았습니다. 2편에서는 이름 짓기를, 3편에서는 함수…