코틀린 디자인 패턴 시리즈 (9) – Decorator 패턴은 상속 대신 어떻게 확장할까
Decorator 패턴은 코틀린에서 기능을 덧붙일 때 상속 계층을 더 만드는 대신 래퍼를 겹쳐 붙이는 방식입니다. 로깅, 압축, 암호화 같은 부가 기능을 composition으로 확장하는 감각을 Kotlin 예제로 정리합니다.
-
-
코틀린 디자인 패턴 (8) – Composite 패턴으로 트리 구조 다루기
코틀린 Composite 패턴은 파일과 폴더처럼 개별 객체와 묶음 객체가 반복되는 트리 구조에서 특히 유용합니다. 호출부에 분기와 재귀를 흩뿌리지 않고, 공통 인터페이스로 전체 트리를 일관되게 다루는 감각을 Kotlin 예제로 정리합니다.
-
코틀린 디자인 패턴 (7) – Bridge 패턴은 상속 폭발을 어떻게 줄일까
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
-
코틀린 디자인 패턴 (6) – Adapter 패턴으로 기존 코드를 새 인터페이스에 맞추기
코틀린 Adapter 패턴은 외부 SDK나 레거시 코드의 인터페이스가 지금 프로젝트와 맞지 않을 때 특히 유용합니다. 단순 변환이면 extension function으로 끝낼 수 있지만, 계약·예외·상태 번역까지 필요하면 별도 Adapter 계층이 더 안전합니다.
-
코틀린 디자인 패턴 (5) – Prototype 패턴과 data class copy 정리
코틀린에서는 data class copy() 덕분에 Prototype 패턴을 가볍게 쓸 수 있습니다. 하지만 copy()는 shallow copy이므로, mutable list나 nested object가 섞이면 언제 deep copy가 필요한지 분명한 판단 기준이 필요합니다.
-
코틀린 디자인 패턴 (4) – Builder 패턴과 named argument는 어떻게 다를까
코틀린에서는 named argument와 default parameter 덕분에 Builder가 덜 자주 필요합니다. 하지만 단계적 조립, 검증, 중첩 구조, Java 호환성까지 고려하면 Builder와 DSL 스타일이 여전히 유효한 순간이 있습니다.
