В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Kotlin Start

620 membersпожаловаться на группу
2019 October 08

F

FOX in Kotlin Start
Andrew Mikhaylov
В твоём примере явно есть обособленное необязательное поведение. Такого не должно быть в интерфейсе.
согласен, разделил интерфейсы на 2 - для записи и для чтения. Теперь у меня разные классы - NetHleper, FileHelper, SQLHelper реализуют их понеобходимости.
Спасибо за подсказку. Подзабыл про SOLID
источник
13:28пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
Я бы не сказал, что это о S из SOLID, потому что у второго интерфейса, который наследует первый, всё равно два поведения. Это вообще не о SOLID. Это просто о том, какие обещания ты декларируешь интерфейсами.
источник
13:29пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
С двумя ты точно говоришь — "вот тут можно только читать, вот тут можно читать и писать". С одним — "тут можно читать и наверное можно писать, я не знаю". Очевидно, первый удобнее в использовании.
источник
13:30пожаловаться

n

neikist in Kotlin Start
Andrew Mikhaylov
Я бы не сказал, что это о S из SOLID, потому что у второго интерфейса, который наследует первый, всё равно два поведения. Это вообще не о SOLID. Это просто о том, какие обещания ты декларируешь интерфейсами.
Я думаю автор говорил про I из солида, но да, это не I
источник
13:31пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
И да, Александр правильно отметил, что котлин ровно такой переход от второго к первому сделал, распиливая джавовые коллекции на два типа.
источник
13:31пожаловаться

F

FOX in Kotlin Start
Andrew Mikhaylov
Я бы не сказал, что это о S из SOLID, потому что у второго интерфейса, который наследует первый, всё равно два поведения. Это вообще не о SOLID. Это просто о том, какие обещания ты декларируешь интерфейсами.
Это вроде I из SOLID. Не?
источник
13:31пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
My bad, читаю задницей. Я даже не знаю, ISP это или нет — формально реализующий интерфейс с дефолтным методом никак от него не зависит, и если дефолтный метод выбросить из интерфейса, реализующий этот класс можно вообще не менять.
источник
13:33пожаловаться

F

FOX in Kotlin Start
Andrew Mikhaylov
С двумя ты точно говоришь — "вот тут можно только читать, вот тут можно читать и писать". С одним — "тут можно читать и наверное можно писать, я не знаю". Очевидно, первый удобнее в использовании.
Так я и не спорю, конечно кода больше, но удобнее в разы. спасибо еще раз на наводку
источник
13:33пожаловаться

AN

Alexander Nozik in Kotlin Start
Andrew Mikhaylov
My bad, читаю задницей. Я даже не знаю, ISP это или нет — формально реализующий интерфейс с дефолтным методом никак от него не зависит, и если дефолтный метод выбросить из интерфейса, реализующий этот класс можно вообще не менять.
Дефолтные реализации, которые не будут реимплементиться лучше вообще в экстеншены выносить
источник
13:35пожаловаться

F

FOX in Kotlin Start
neikist
Я думаю автор говорил про I из солида, но да, это не I
Ну, тут подходит и принцип разделеняи интерфейсов, и принцип единой ответственности
источник
13:35пожаловаться

n

neikist in Kotlin Start
FOX
Ну, тут подходит и принцип разделеняи интерфейсов, и принцип единой ответственности
SRP скорее о реализации а не о контрактах
источник
13:36пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
Alexander Nozik
Дефолтные реализации, которые не будут реимплементиться лучше вообще в экстеншены выносить
Только если они гарантировано не будут реимплементиться. Если их можно реимпмлементить с целью повышения перформанса, why not.
источник
13:37пожаловаться

F

FOX in Kotlin Start
Кстати, вот что хотел еще спросить, я так понимаю что давать другое название переменной в классе, реализующем интерфейс - плохая практика?
источник
13:37пожаловаться

AN

Alexander Nozik in Kotlin Start
Andrew Mikhaylov
Только если они гарантировано не будут реимплементиться. Если их можно реимпмлементить с целью повышения перформанса, why not.
ну я именно про случай, когда это не часть поведения, а просто удобные переопределения методов
источник
13:38пожаловаться

AN

Alexander Nozik in Kotlin Start
FOX
Кстати, вот что хотел еще спросить, я так понимаю что давать другое название переменной в классе, реализующем интерфейс - плохая практика?
Ну зависист. Если нет для этого мотивации, то да, лучше, чтобы было единообразно. Но иогда и осмысленно, например если класс дженерик, а у объекта наследника какой-то новый смысл возникает. Идея не рекомендует.
источник
13:39пожаловаться

F

FOX in Kotlin Start
Alexander Nozik
Ну зависист. Если нет для этого мотивации, то да, лучше, чтобы было единообразно. Но иогда и осмысленно, например если класс дженерик, а у объекта наследника какой-то новый смысл возникает. Идея не рекомендует.
Вот пример.
interface DataProvider<T> {
    fun getData(file: T): String
}

но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
class NetHelper:DataProvider<String> {
    override fun getData(link: String): String {}
}
источник
13:41пожаловаться

AN

Alexander Nozik in Kotlin Start
FOX
Вот пример.
interface DataProvider<T> {
    fun getData(file: T): String
}

но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
class NetHelper:DataProvider<String> {
    override fun getData(link: String): String {}
}
Ну вполне.
источник
13:41пожаловаться

AM

Andrew Mikhaylov in Kotlin Start
Это про возможность вызывать функцию с указанием имён параметров, и там можно схлопотать себе паззлер. Но я не помню, в чём его суть, если честно.
источник
13:42пожаловаться

F

FOX in Kotlin Start
Alexander Nozik
Ну вполне.
Согласен, но IDEA не то чтобы ругается, а предупреждает о смене имени переменной
источник
13:42пожаловаться

AN

Alexander Nozik in Kotlin Start
FOX
Согласен, но IDEA не то чтобы ругается, а предупреждает о смене имени переменной
Ну потому что это потенциальный источник ошибок. Она не жестко ругается. Можно следовать, можно не следовать
источник
13:42пожаловаться