В вашем примере делегирование используется не совсем так, как обычно, поэтому вы не видите преимущества.
DeliveryQueen
перенаправляет вызов метода в экземпляр чего-либо, реализующего FoodDelivable
, который является нормальным шаблоном; но ваш случай имеет два важных отличия:
- он может изменить эту реализацию после создания, и
- метод пересылки (
orderSomeFood()
) не тот, который он пересылает (deliverSomeFood()
).
Если бы не это, вы могли бы реализовать этот класс просто:
class DeliveryQueen(orderedFood: FoodDeliverable): FoodDeliverable by orderedFood
… и без тела (кроме любых методов, которые вы необходимо добавить или переопределить).
(См. эти вопросы , почему Kotlin не поддерживает изменение делегата во время выполнения.)
Очевидно, что такой игрушечный пример не очень хорошо демонстрирует преимущества делегирования. Но представьте, если бы у FoodDeliverable
было еще много методов; без поддержки делегирования Kotlin для DeliveryQueen
потребуется множество шаблонов, таких как:
fun deliverSomeFood() {
orderedFood.deliverSomeFood()
}
fun payDriver(price: BigDecimal, tip: BigDecimal) {
orderedFood.payDriver(price, tip)
}
fun leaveReview(comment: String, stars: NumberOfStars, promptness: EarlyOrLate, foodQuality: QualityMetric): Review {
return orderedFood.leaveReview(comment, stars, promptness, foodQuality)
}
fun <T : ConnectionMethod> contactRestaurant(method: T): Connection<T> {
return orderedFood.contactRestaurant(method)
}
// …and so on…
… все из которых необходимо поддерживать в актуальном состоянии.
(Количество методов может быть довольно большим. Например, я помню, что мне нужно было написать обертку в Java для java.sql.Connection
, что более чем 50 методов ... Делегация сэкономила бы значительных шаблонных образцов! )