Вы понимаете, что эта функция сама это состояние не меняет?
Конечно. Какая разница, кто меняет состояние? Если бы это состояние влияло бы еще на что-то, или могло меняться откуда-то еще и при этом не сбрасывалось само, то да. Но это все не наш случай.
И, строго говоря, это не функция сбрасывает занчение, а лябда, которая будет вызвана когда-то потом. Так что даже тут вы не совсем правы.
С точки зрения английского языка, потому что конструкция относится к нему.
А, английского :) Я сначала подумал вы про язык Java. Ну с т.з. английского я уже писал. Как раз с т.з. английского языка тут все хорошо. Стейтмент читается прям по грамматике.
Функция всегда устанавливает значение в true и возвращает значение, которое было до этого, т.е. до вызова функции, именно предыдущее. Когда функция возвращает false она гарантированно возвращает устаревшее значение, которое она сама и поменяла. Прошедшее время она вообще никак не проверяет, кстати.
Она и не должна проверять время. Время за нее хэндлер определит. Это значение не «устаревшее», а как раз актуальное. Сама она его выставила или нет — неважно. Для клиент есть только один вопрос, продолжать или нет испольнение обработчика. Все остальное не его дело и ни про что он знать не должен. Ни просто статические поля ни про время прошедшее. Это и называется «никапсуляция».
Давайте очень просто. Вы функции называете по тому, что они делают, или что они возвращают? Если первое, то функция должна называться lockClick, если второе — wasClickLocked, правда тогда у вас половина функций должна называться void. Если третье — озвучьте.
Ну если очень просто, то я функции называю по смыслу их действий в соотвествии а английски языком, т.к. нахожусь в англоговорящей зоне. В данном случае она «проверяет блокировку и захватывает, если ее нет». Кроме того, я учитываю использование функции. Если ее называть lockClick, то надо инвертировать результат, что либо приводит опять к смени имени либо засоряет код постоянными отрицаниями результата.
Я правильно понимаю, что вы предпочтете везде делать инверсию возвращаемого значения? Андроид Струдия, кстати, на это ругается втроенным инспекшеном.
Вам несколько человек объяснили, что вы делаете фигню и специально выбираете название, которое противоречит тому, что функция делает. Изначальный код у вас следовал тем самым конвенциям, теперь у вас смесь зачем-то.
Эти несколько человек высказали свои аргументы, я высказал контр аргументы и основания почему именно так. Изначальный код также не следовал _вашим_ конвенциям, см. «isClickedLately».
P.S. Почитайте хотя бы одну конвенцию, увидите что методы должны начинаться с глагола, например.
Все правильно, is — глагол. Ну и кроме того, я вполне допускаю, что можно принимать конвенцию как жесткое правило. Что по поводу инверсии результата? Вполне возможно, что вы так и делаете и вы не имеете права называть методы более подходяще ситуации. У нас нет таких жестких правил. И не надо натягивать свои конвенции на всех. Мое название не противоречит конвенции по вашей ссылке. По крайней мере Java разделу.
PS: Кроме того, предполагается что, мы тут общаемся на равных. Поэтому постарайтесь избегать консрукций в стиле «вам объяснили». Я вам ничего не должен, а вы не в своей шаражке джуниоров пинаете. В особенности по поводу «предпочтений». Давайте без хамства.
Я все еще хотел бы узнать ответ про инверсию возвращаемого значения в случае вашего варианта называния.
Ну да, состояние в конкретный момент вызова этой функции. Ну и что что меняется? Вы когда вызываете любую функцию, она возвращает занчение в конкреный момент. И это значение может меняться.
Например, прям вот самые кишки андроида: BluetoothAdapter.getDefaultAdapter().isEnabled()
Возварщает занчение логическое, в конкретный момент. Через долю секунды это значение может поменяться в результате работы другого приложения или дейсвий пользователя или еще чего. И повторный вызов вернет другое значение вас тоже не устраивает?
Что значит «нелогично с точки зрения языка»? У языка нет т.з. Есть синтаксис. А как им выражать то, что требуется дело программиста.
То вы про какие-то конвенции, которые не можите привести, то про про какое-то требование к постоянству возвращаемого результата… логика языка какая-то…
Кстати, название lockClick тоже неплохое. Но тогда придется ей инвертировать возвращаемое значение, либо все время добавлять! перед вызывом. Либо в скобках писать тело метода. Я старался сделать код как можно короче.
PS: Функция возвращает не предыдущее значение. Она возращает значение в зависимости от прошедшего времени. Что и требуется в рамках задачи.
Ну так она и объясняет. Тринарный оператор это синтаксический сахар. На него не следует ориентироваться. Это как сокращения в естественном языке. Приемлемы, но только в определнных местах и контексте. О какой конкретно конвенции идет речь? Я серьезно? Про геттеры знаю. Про произвольные функции вроде ничего такого не помню.
Про побочные эффекты я настаиваю, что их нет. Все эффекты в данном случае суть часть этой функции. Ничего за пределами идеи и контекста функции она не делает. В этом вся фишка решения.
Вообще, название функции это чисто вкусовщина, а конвенции это просто рекомендации. Поэтому, я готов признать, что называние неудачное, если кто-то предложит более подходящее. Филосовские рассуждения о том как неправильно можно вести до бесконечности.
Это не вопросительное предложение. Это конструкция с if. По английски не говорят if is apple unripe, don't eat it. Говорят if apple is unripe, don't eat it. На мой взгляд код проще читать если он чатается (извиняюсь за тавтологию) как нормальная фраза. Так же, то, что метод начинается не с is, говорит о том, что это не просто геттер. Что-то внутри делается. А так да, по стандарту Java, геттер возвращающий boolean должен начинаться с is. Но это не просто геттер.
Ну да ладно. Я же не спорю, что может быть можно получше назвать. Так кто-нибудь может скажет лучшее называние? А то как-то немного не корретная дискуссия выходит :(
Под неочевидной логикой обычно понимаются сайдэффекты. В данном случае никаких сайдэффектов нет. Название метода это всегда слишком коротко, что бы описать ВСЕ, что в нем происходит. Тут никаких сайдэффектов нет. Все что происходит внутри метода влияет только на результат этого метода.
Метод предельно просто. Что бы «вспонить» что он делает, достаточно один раз взглянуть внутрь. Если работаешь с незнакомым (или хорошо забытым) кодом, все равно надо смотреть что внутри.
Звучит как вопрос. А по поводу сайд-эффекта, ну и что? Этот эффект инкапсулирован в этом методе. Клиенту он недоступен, так что тут все нормально.
3. Да. Надо так делать если операция долгая. Так же ее надо выносить в бэкграунд и показывать прогресс. Это все да. Но как бы речь изначально о легаси коде. И речь о дребезге, не более. Т.е. конечно так нельзя блокировать на длительное время, которое значимо для человеческой сознательной реакции.
Ну в приципе согласен. Просто в моем случае жц не используется в приложении совсем. Я об этом как-то не думал. Как выше сказал господин kukovik, по хорошему конечно надо управлять UI, но об этом надо думать на этапе проектирования. Но это не всегда оправдано, поэтому даже в заголовке есть слово «велосипед» :)
А зачем вообще примешивать сюда Lifecycle? Нам без разницы, есть ли активити и какая. Может активити уже давно уничтожена. Лямда выполниться в любом случае через заданное время.
Я просто хочу еще раз подчеркнуть, это один из вариантов решения проблемы дребезга (debounce), а не попытка дизаблить недоступные по бизнеслогике части интерфейса. Для этого требются совсем другие подходы.
Не понял, зачем его терминейтить? Это один нстанс в статическом поле. Он используется для всех вызовов. Насколько я понмаю, моя реализация не имеет никакого отношения к Lifecycle.
Ну да. Это примерно тоже самое, что и в вашем примере с экстеншеном. В принципе можно и так, но наследование ради этого, ИМХО лишнее.
Ну и писать будет неудобно. Каждый раз надо явно создавать инстанс наследника (много болерплейта). Опять же надо где-то хранить либо время либо флаг. Вобщем это не улучшает на мой взгляд ничего, а добавляет наследование. Которое абсолютно никчему.
В любом случае это таже вкусовщина. Кто-то любит наследование, кому-то проще без него. Это принципиально ничего не меняет и не делает решение более компактным и изолированным.
Да, View корень иерархии виджетов. Но тут я имел ввиду ListView. И под Item a подразумевал item из ListView, на котором произошел клик. Т.е. OnItemClickListener.
Я не увеерн, наверное можно будет привязаться к инстансу самого ListView или к View айтема… Но это опять же дополнительный код, если я правильно понял.
Что именно сложно? И что именно непонятно?
Используется один метод. Именно статик переменная там и используется.
Зачем обновлять время и сравнивать, если можно обойтись без этого?
А синглтон то тут причем вообще!?
Еще раз, это все на Java. Java не имеет экстешенов. Давайте придерживаться темы и заданных условий.
Но это же будет работать только для наследников View? Ну лично я не люблю засовывать в тэги, но это мое личное дело :)
Мою реализацию так же можно использовать при клике на Item в ListView. Я на этом не акцетировал внимание, наверное зря, но в примере использования именно дребезг на айтеме листвью фильтруется.
В вашем случае надо будте делать отдельный экстеншен.
Насколько язнаю, в Java нет extensions. По крайней мере под андроид. Можно конечно его вручную эмулировать, но зачем?
Если это офромить и в качестве экстешена. Тогда для каждого отдельного View будет отдельный счетчик времени и флаг, либо, как по условию, кнопки не разделяются, все равно надо какой-то статический флаг где-то хранить.
Я не понял, что значит «фильтровать» наружу?
И независимо от того, экстеншен это или нет, надо как-то определять когда начать и когда перестат фильтровать клики.
1. Ну как бы да. Она еще ко многим задачам не подойдет. Но вообще это блокировка «дребезга» кнопки. Т.е. для простейших случаев, где надо просто чуть-чуть подождать перед тем как дать возможность кликнусть второй раз. Как я написал в статье, я не смог придумать кейса где надо именно только одну кнопку блокировать. Поэтому в «требованиях» к «новому решению» первым пунктом идет что нет необходимости разделять кнопки.
2. Помоему название вполне подходит, в условии, если клик заблокирован, то выход. Но тут думаю большедело вкуса. Код прям по английски читается: Если клик заблокирован — выход: if (MultiClickFilter.clickIsLocked()) return;
Хотя, интересно было бы узнать ваш вариант названия?
3. Да, они свидетельствуют. Тем не мение, можно рассуждать о сферических идеальных архетектурах, а можно решить трубуемую задачу быстро, просто, и изолировано. И да, это как раз блокирует пользователя через UI. Ну либо я не понял, что значит «блокировать через UI». Поясните?
PS Я понял, что велосипед не ваш, но может быть вы передадите также автору?
Я не очень понял, почему L298N не позвояет управлять скоростью? Вроде у меня тоже китайский комплект. И все прекрасно управляется шимом при питании в пять вольт.
Конечно. Какая разница, кто меняет состояние? Если бы это состояние влияло бы еще на что-то, или могло меняться откуда-то еще и при этом не сбрасывалось само, то да. Но это все не наш случай.
И, строго говоря, это не функция сбрасывает занчение, а лябда, которая будет вызвана когда-то потом. Так что даже тут вы не совсем правы.
А, английского :) Я сначала подумал вы про язык Java. Ну с т.з. английского я уже писал. Как раз с т.з. английского языка тут все хорошо. Стейтмент читается прям по грамматике.
Она и не должна проверять время. Время за нее хэндлер определит. Это значение не «устаревшее», а как раз актуальное. Сама она его выставила или нет — неважно. Для клиент есть только один вопрос, продолжать или нет испольнение обработчика. Все остальное не его дело и ни про что он знать не должен. Ни просто статические поля ни про время прошедшее. Это и называется «никапсуляция».
Ну если очень просто, то я функции называю по смыслу их действий в соотвествии а английски языком, т.к. нахожусь в англоговорящей зоне. В данном случае она «проверяет блокировку и захватывает, если ее нет». Кроме того, я учитываю использование функции. Если ее называть lockClick, то надо инвертировать результат, что либо приводит опять к смени имени либо засоряет код постоянными отрицаниями результата.
Я правильно понимаю, что вы предпочтете везде делать инверсию возвращаемого значения? Андроид Струдия, кстати, на это ругается втроенным инспекшеном.
Эти несколько человек высказали свои аргументы, я высказал контр аргументы и основания почему именно так. Изначальный код также не следовал _вашим_ конвенциям, см. «isClickedLately».
Все правильно, is — глагол. Ну и кроме того, я вполне допускаю, что можно принимать конвенцию как жесткое правило. Что по поводу инверсии результата? Вполне возможно, что вы так и делаете и вы не имеете права называть методы более подходяще ситуации. У нас нет таких жестких правил. И не надо натягивать свои конвенции на всех. Мое название не противоречит конвенции по вашей ссылке. По крайней мере Java разделу.
PS: Кроме того, предполагается что, мы тут общаемся на равных. Поэтому постарайтесь избегать консрукций в стиле «вам объяснили». Я вам ничего не должен, а вы не в своей шаражке джуниоров пинаете. В особенности по поводу «предпочтений». Давайте без хамства.
Я все еще хотел бы узнать ответ про инверсию возвращаемого значения в случае вашего варианта называния.
Например, прям вот самые кишки андроида: BluetoothAdapter.getDefaultAdapter().isEnabled()
Возварщает занчение логическое, в конкретный момент. Через долю секунды это значение может поменяться в результате работы другого приложения или дейсвий пользователя или еще чего. И повторный вызов вернет другое значение вас тоже не устраивает?
Что значит «нелогично с точки зрения языка»? У языка нет т.з. Есть синтаксис. А как им выражать то, что требуется дело программиста.
То вы про какие-то конвенции, которые не можите привести, то про про какое-то требование к постоянству возвращаемого результата… логика языка какая-то…
Кстати, название lockClick тоже неплохое. Но тогда придется ей инвертировать возвращаемое значение, либо все время добавлять! перед вызывом. Либо в скобках писать тело метода. Я старался сделать код как можно короче.
PS: Функция возвращает не предыдущее значение. Она возращает значение в зависимости от прошедшего времени. Что и требуется в рамках задачи.
Про побочные эффекты я настаиваю, что их нет. Все эффекты в данном случае суть часть этой функции. Ничего за пределами идеи и контекста функции она не делает. В этом вся фишка решения.
Вообще, название функции это чисто вкусовщина, а конвенции это просто рекомендации. Поэтому, я готов признать, что называние неудачное, если кто-то предложит более подходящее. Филосовские рассуждения о том как неправильно можно вести до бесконечности.
Как правильно назвать функцию в данном случае?
Ну да, без rx никак не обойтись…
Каких тут телодвижений много? Один if в одну строчку.
О каких вы телодвижениях говорите?
Ну да ладно. Я же не спорю, что может быть можно получше назвать. Так кто-нибудь может скажет лучшее называние? А то как-то немного не корретная дискуссия выходит :(
Под неочевидной логикой обычно понимаются сайдэффекты. В данном случае никаких сайдэффектов нет. Название метода это всегда слишком коротко, что бы описать ВСЕ, что в нем происходит. Тут никаких сайдэффектов нет. Все что происходит внутри метода влияет только на результат этого метода.
Метод предельно просто. Что бы «вспонить» что он делает, достаточно один раз взглянуть внутрь. Если работаешь с незнакомым (или хорошо забытым) кодом, все равно надо смотреть что внутри.
2. Ну если читать по английски, получится вопрос:
if (MultiClickFilter.clickIsLocked()) return;
Звучит как вопрос. А по поводу сайд-эффекта, ну и что? Этот эффект инкапсулирован в этом методе. Клиенту он недоступен, так что тут все нормально.
3. Да. Надо так делать если операция долгая. Так же ее надо выносить в бэкграунд и показывать прогресс. Это все да. Но как бы речь изначально о легаси коде. И речь о дребезге, не более. Т.е. конечно так нельзя блокировать на длительное время, которое значимо для человеческой сознательной реакции.
Я просто хочу еще раз подчеркнуть, это один из вариантов решения проблемы дребезга (debounce), а не попытка дизаблить недоступные по бизнеслогике части интерфейса. Для этого требются совсем другие подходы.
Ну и писать будет неудобно. Каждый раз надо явно создавать инстанс наследника (много болерплейта). Опять же надо где-то хранить либо время либо флаг. Вобщем это не улучшает на мой взгляд ничего, а добавляет наследование. Которое абсолютно никчему.
В любом случае это таже вкусовщина. Кто-то любит наследование, кому-то проще без него. Это принципиально ничего не меняет и не делает решение более компактным и изолированным.
Я не увеерн, наверное можно будет привязаться к инстансу самого ListView или к View айтема… Но это опять же дополнительный код, если я правильно понял.
Используется один метод. Именно статик переменная там и используется.
Зачем обновлять время и сравнивать, если можно обойтись без этого?
А синглтон то тут причем вообще!?
Еще раз, это все на Java. Java не имеет экстешенов. Давайте придерживаться темы и заданных условий.
Мою реализацию так же можно использовать при клике на Item в ListView. Я на этом не акцетировал внимание, наверное зря, но в примере использования именно дребезг на айтеме листвью фильтруется.
В вашем случае надо будте делать отдельный экстеншен.
Если это офромить и в качестве экстешена. Тогда для каждого отдельного View будет отдельный счетчик времени и флаг, либо, как по условию, кнопки не разделяются, все равно надо какой-то статический флаг где-то хранить.
Я не понял, что значит «фильтровать» наружу?
И независимо от того, экстеншен это или нет, надо как-то определять когда начать и когда перестат фильтровать клики.
Не могли бы вы показать свой пример реализации?
2. Помоему название вполне подходит, в условии, если клик заблокирован, то выход. Но тут думаю большедело вкуса. Код прям по английски читается: Если клик заблокирован — выход: if (MultiClickFilter.clickIsLocked()) return;
Хотя, интересно было бы узнать ваш вариант названия?
3. Да, они свидетельствуют. Тем не мение, можно рассуждать о сферических идеальных архетектурах, а можно решить трубуемую задачу быстро, просто, и изолировано. И да, это как раз блокирует пользователя через UI. Ну либо я не понял, что значит «блокировать через UI». Поясните?
PS Я понял, что велосипед не ваш, но может быть вы передадите также автору?
Можно схему посмотреть?
Если что, то мой набор типа такого.
sitten → sittin (замена «i» на «e»)
Наоборот наверное?