Слушатель событий и обработчик событий - это два термина, которые вызывают путаницу. Особенно в Котлине, где граница между ними была размыта. Здесь я пытаюсь упростить.
Общее определение слушателей и обработчиков намного шире, чем его использование в Android. Вот популярные определения:
прослушиватель следит за запуском события.
обработчик отвечает за обработку события.
Это может сбивать с толку, потому что часто один и тот же объект прослушивает события и обрабатывает их. Хотя обычно предполагается, что когда мы устанавливаем анонимный класс в качестве слушателя, его методы являются фактическими обработчиками:
cancelImage.setOnClickListener(object : View.OnClickListener { //1 override fun onClick(v: View?) { // 2 dismiss() } })
- Анонимный класс здесь используется как слушатель
- Метод
onClick
находится здесь обработчик события
Мы можем использовать именованные классы в качестве слушателей:
class OnCancelSnackListener( val snackbar: Snackbar ): View.OnClickListener { override fun onClick(v: View?) { snackbar.dismiss() } }
Использование:
cancelImage.setOnClickListener(OnCancelSnackListener(this))
Слушатели часто являются объектами, поэтому они обычно имеют суффикс Listener
. Обработчики обычно не имеют суффикса, но вместо этого они чаще всего имеют префикс on
(onClick
, onSwipe
и т. Д.). Обратите внимание, что это более проблематично, когда мы устанавливаем слушателя с использованием лямбда-выражения:
cancelImage.setOnClickListener { dismiss() }
Что это за лямбда-выражение? Слушатель или обработчик? Формально он определяет, как следует обрабатывать событие. Объект слушателя генерируется Kotlin под капотом. Означает ли это, что когда мы называем функцию, которая принимает обработчик, мы должны называть ее суффиксом Handler
(например, setOnClickHandler
)? Нисколько. Хотя вы можете найти такие подходы в некоторых JS-библиотеках, например ExJS:
handler: function() { } listeners: { 'click': function() { } }
Соглашение в Java, как и в большинстве других языков, заключается в использовании суффикса Listener
по историческим причинам! Вы можете узнать в коде Kotlin stdlib и JetBrains Kotlin, что Kotlin также принимает это соглашение. Таким образом, вы можете с уверенностью определить следующие функции:
fun setOnLoadedListener(handler: ()->Unit) { // Code } fun addOnFlingListener(handler: ()->Unit) { // Code }
Также вы можете определить следующие функции:
fun setOnLoadedListener(listener: ()->Unit) { // Code } fun addOnFlingListener(listener: ()->Unit) { // Code }
Просто помните, что это хорошая практика - сформулировать одно соглашение для проекта и уважать его.
Этот пост является пятнадцатой частью словаря программистов Kotlin. Чтобы быть в курсе последних новостей, просто подпишитесь на этот канал или следите за мной в Твиттере. Если вам нужна помощь, помните, что Я открыт для консультации.
Если вам это нравится, не забудьте хлопать. Обратите внимание: если вы удерживаете кнопку хлопка, вы можете оставить больше хлопков.
Вот и другие части словаря программистов Kotlin:
- Аргумент против параметра, аргумент типа против параметра типа
- Заявление vs выражение
- Функция vs метод vs процедура
- Поле против собственности
- Класс против типа против объекта
- Выражение объекта против объявления объекта
- "Получатель"
- Неявный получатель против явного получателя
- Внутренний приемник vs Диспетчерский приемник
- Тип приемника vs объект приемника
- Тип функции против функционального литерала против лямбда-выражения против анонимной функции
- Функция высшего порядка
- Функциональный литерал с приемником vs Тип функции с приемником
- Инвариантность vs Ковариация vs Контравариантность
- Делегация vs композиция