Comments 7
А когда все-таки будет релиз?)
Думаю, в подавляющем большинстве случаев все свойства класса будут использовать один и тот же делегат. Поэтому было бы удобно указывать его один раз на уровне описания класса. Как вариант: если класс имплементирует интерфейс делегата, то он сам является делегатом для своих свойств, а также для свойств всех его потомков. Концепт делегата в этом случае играет роль интерсептора для свойств. Таким образом, мы можем создать целую domain model с заданным функционалом, описав делегат только для базового класса.
Те юзкейсы, на которые мы смотрели, не подтверждают эту гипотезу. Один делегат бывает, когда данные хранятся централизованно (map или база данных), но это не подавляющее большинство случаев.
Этот случай как раз я и имел ввиду, например реализация ORM при помощи делегатов. Или более сложный кейс, когда есть одна модель, и требуется динамически менять ее поведение в зависимости от контекста: на сервере замепить в DB, на транспортном уровне мепить в XML, а на клиенте добавить возможность отслеживать изменения (PropertyChangeListeners). На данный момент это решается достаточно сложно при помощи магии фреймворков, AOP, проксирования, code enhancement, etc… Если добавить базовые возможности AOP в язык, такие как interceptor-ы для свойств, было бы на порядок проще реализовывать подобные решения.
Делегаты позволяют сделать интерсепторы для свойств относительно дешево: вместо каких-нибудь аннотаций указываем делегата и радуемся. Я понимаю, что просто один раз написать на классе «делегировать все сюда» — выглядит здорово, но на самом деле мы не можем в этом случае никакой type-safety гарантировать, а это важно. Так что необходимость писать делегата для каждого свойства — это такой компромисс. А писать там совсем не много.
Чувствую, что делегаты помогли бы сделать поля в которые значения инжектируются (например) спрингом более подходящего для них типа, например readonly и not-null, но что-то не могу пока понять как.
Sign up to leave a comment.
Kotlin M5.3: Delegated Properties