코틀린 확장 함수는 왜 편할까: 상속 없이 기능을 붙이는 방법
코틀린 확장 함수를 receiver, 멤버 함수 우선순위, nullable receiver 기준으로 정리합니다. 상속 없이 기능을 붙일 때의 장점과 한계, 남용하기 쉬운 지점과 사용 기준도 실제 코드 예제로 설명합니다.
-
-
코틀린 디자인 패턴 시리즈 (22) – Template Method 패턴과 함수형 대안
Template Method 패턴과 higher-order function 차이를 코틀린 관점에서 깊게 비교합니다. 공통 흐름을 상속으로 고정할지, 함수 인자로 변하는 단계를 주입할지 실무 기준으로 정리합니다.
-
코틀린 디자인 패턴 (7) – Bridge 패턴은 상속 폭발을 어떻게 줄일까
코틀린 Bridge 패턴은 알림 종류와 발송 채널처럼 서로 독립적으로 늘어나는 축이 있을 때 특히 유용합니다. 상속 계층 하나로 조합을 다 감당하려 하면 클래스가 금방 불어나기 때문에, Bridge는 abstraction과 implementation을 분리해 상속 폭발을 줄이는 방향을 제시합니다.
-
상속보다 조합이 더 나은 순간: 객체지향 설계에서 조합을 고르는 기준
상속보다 조합이 더 나은 순간은 분명합니다. 이 글에서는 객체지향 설계에서 조합을 고르는 기준을 변경 비용, 역할 재사용, 위임, 치환 가능성, 옵션 조합 관점으로 실무적으로 정리합니다.
-
리스코프 치환 원칙(LSP)은 왜 자주 오해될까: 상속보다 계약을 먼저 봐야 하는 이유
리스코프 치환 원칙(LSP)을 상속 문법이 아니라 계약과 치환 가능성 관점에서 다시 설명합니다. 상속이 자연스러운지 판단하는 실전 질문과 구체적인 위반 사례까지 함께 정리합니다.
-
상속 vs 조합: inheritance와 composition 비교
상속과 조합은 모두 객체지향 설계의 도구지만, 변경이 생기는 상황에서는 composition이 inheritance보다 더 유연하게 버티는 경우가 많습니다. 이 글에서는 알림 발송 구조를 예시로 상속과 조합의 차이를 코드와 다이어그램으로 자세히 설명합니다.
