델리게이션을 통한 확장

• 상속과 델리게이션 모두 객체지향 프로그래밍의 디자인 방식
• 상속은 강력하고 자주 사용된다 → 강력하게 묶이고 수정할 수 없음
• 델리게이션은 상속보다는 유연하다
• 상속 → 부모 자식 관계, 부모를 바꿀 수 없음
• 델리게이션 → 자식간에 친구 관계, 서로 다른 친구를 사귈 수 있음
• 자바는 상속에 대해 많은 지원을 했고 상대적으로 델리게이션에 대해서는 지원이 약했음

상속 대신 델리게이션을 써야 하는 상황

• 클래스의 객체가 다른 클래스의 객체가 들어갈 자리에 쓰여야하면 상속을 사용한다
• 클래스의 객체가 단순히 다른 클래스의 객체를 사용만 해야 하면 델리게이션을 사용하자

위 그림에서 상속과 델리게이션의 차이점을 볼 수 있다

• 베이스 클래스에서 상속받은 인스턴스를 자식 클래스에서 마음대로 바꾸려하는 행동은 오류를 일으킬 수 있음
• 부모 클래스의 메소드를 오버라이드할 때 베이스 클래스의 외부 동작을 유지해야 함 (LSP - 리스코프 치환 원칙) → 엄청난 제약 사항
• 클래스의 구현을 새로 하거나 한 클래스의 인스턴스를 ‘개는 동물이다’와 같이 포함 관계에 있는 다른 클래스로 대체할 땐 상속을 사용하자
• 오직 다른 객체의 구현을 재사용하는 경우라면 델리게이션을 사용하자

델리게이션을 사용한 디자인

잘못된 경로로의 상속

// project1.kt

interface Worker {
	fun work()
	fun takeVacation()
}

open class JavaProgrammer: Worker {
	override fun work() = println("...write Java...")
	override fun takeVacation() = println("...code at the beach...")
}

class CSharpProgrammer: Worker {
	override fun work() = println("...write C#...")
	override takeVacation() = println("...branch at the ranch...")
}

// 1번 Manager
// class Manager: JavaProgrammer()

/**
 * 2번 Manager 
 * class Manger(val worker: Worker) {
 * 	fun work() worker.work()
 * 	fun takeVacation() = worker.work() // 쉬는게 쉬는게 아니다
 * }
 */

// 3번 Manager
class Manager() : Worker by JavaProgrammer()

fun main() {
	val doe = Manager()
	doe.work() //...write Java...
	val coder: JavaProgrammer = doe //Error: type mismatch
}