코틀린 디자인 패턴 (7) – Bridge 패턴은 상속 폭발을 어떻게 줄일까
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
헥사고날 아키텍처를 그림이 아니라 의존 방향, 테스트 격리, 외부 시스템 교체 비용 관점에서 쉽게 설명합니다. ports and adapters가 언제 유용하고 언제 과설계가 되는지 실무 기준으로 정리합니다.
안드로이드 MVI 패턴이 언제 잘 맞는지, MVVM과 무엇이 다른지 상태 흐름 관점에서 정리합니다. reducer 직관, 이벤트 처리, 안전한 화면의 조건, 무거워지는 지점까지 실무 기준으로 설명합니다.
안드로이드에서 single activity 구조가 많아진 이유는 액티비티를 하나로 줄이는 유행 때문만은 아닙니다. Navigation Component, back stack, shared state, Compose, state restoration을 한 흐름으로 다루기 쉬워졌기 때문입니다. 이 글에서는 그 이유와 한계를 실무 관점으로 정리합니다.
코틀린 Adapter 패턴은 외부 SDK나 레거시 코드의 인터페이스가 지금 프로젝트와 맞지 않을 때 특히 유용합니다. 단순 변환이면 extension function으로 끝낼 수 있지만, 계약·예외·상태 번역까지 필요하면 별도 Adapter 계층이 더 안전합니다.
클린 아키텍처가 왜 어렵게 느껴지는지, 계층보다 의존 방향이 왜 핵심인지, 그리고 무엇을 먼저 분리해야 하는지 실무 기준으로 정리합니다.