코틀린 디자인 패턴 (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 스타일이 여전히 유효한 순간이 있습니다.
-
코틀린 디자인 패턴 시리즈 (3) – Abstract Factory 패턴은 언제 필요할까
코틀린에서 Abstract Factory 패턴은 객체를 많이 만드는 기술보다 서로 관련된 제품군을 일관되게 생성하는 구조에 가깝습니다. 이 글에서는 Factory Method와의 차이, 유용한 경우, 과한 경우를 쉬운 예제로 정리합니다.
-
코틀린 디자인 패턴 시리즈 (2) – Factory Method 패턴으로 생성 책임 나누기
Factory Method 패턴을 코틀린 예제로 쉽게 풀어 설명합니다. 생성 책임을 왜 나눠야 하는지, companion object나 factory function과는 언제 다르게 봐야 하는지 함께 정리합니다.
-
코틀린 디자인 패턴 시리즈(0) – 왜 아직도 디자인 패턴을 배워야 할까
코틀린은 전통적인 패턴 구현을 더 간결하게 만들 수 있지만 설계 문제 자체를 없애지는 못합니다. 이 글에서는 왜 코틀린 디자인 패턴을 다시 배워야 하는지와 시리즈 전체 지도를 함께 정리합니다.
