F
Ну потому что это потенциальный источник ошибок. Она не жестко ругается. Можно следовать, можно не следовать
Верно. Но вы так напрмиер делали? И нормально ли это? Или же лучше везде указывать одно имя переменной?
Size: a a a
2019 October 08
AN
Верно. Но вы так напрмиер делали? И нормально ли это? Или же лучше везде указывать одно имя переменной?
я где как. Где-то следую совету идеи, где-то не следую. По обстоятельствам.
F
@noraltavir @r4zzz4k спасибо за конструктивное общение!
M
Вот пример.
но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
interface DataProvider<T> {
fun getData(file: T): String
}но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
class NetHelper:DataProvider<String> {
override fun getData(link: String): String {}
}В некоторых случаях приходится менять название, когда реализуешь что-то из Java, иначе будет
(‘object’: Object)D
Вот пример.
но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
interface DataProvider<T> {
fun getData(file: T): String
}но напрмиер класс NetHelper, который получает данные из сети также реализует этот интерфейс, и там не файл, а ссылка на JSON. поэтому логично было бы сделать так
class NetHelper:DataProvider<String> {
override fun getData(link: String): String {}
}Мне кажется, было бы правильнее не использовать название переменной file в базовом интерфейсе. Очень на uri похоже
AM
Или даже source, да.
D
resourcePath/resourceId
D
Или даже source, да.
+
D
А если нужно красиво работать с конкретной иплементацией
JsonDataSource - завести алиас fun JsonDataSource.getByUrl() = ...F
Или даже source, да.
да, можно и source
F
Если класс реализует интерфейс, то к его названию обычно добавляют - Impl ?
F
Часто такое встречаю
AM
Обычно если у вас интерфейс реализует ровно один класс, то вам, вполне вероятно, не нужен интерфейс. Поэтому соглашения касательно того, как обзывать такие классы, нет.
AM
Но в быту я тоже обычно встречаю InterfaceNameImpl.
F
Но в быту я тоже обычно встречаю InterfaceNameImpl.
получается что если класс FileHelper реализует интерфейс DataProvider то можно писать FileHelperImpl : DataProvider?
AM
получается что если класс FileHelper реализует интерфейс DataProvider то можно писать FileHelperImpl : DataProvider?
Нет, если у вашего класса есть обоснованное название, никакие суффиксы ему приписывать не надо. Это не дотнет, где принято интерфейсы от классов названиями отделять.
F
Обычно если у вас интерфейс реализует ровно один класс, то вам, вполне вероятно, не нужен интерфейс. Поэтому соглашения касательно того, как обзывать такие классы, нет.
Согласен. У меня 3 низкоуровневых класса для работы с данными - файлы, по сети и база SQLite. Я сделал интерфейс для работы с ними. А бизнес логика уже обрабатывается в высокоуровневом классе
F
@r4zzz4k ясно, спасибо.
AM
Out of curiosity: did you try to check that via IDE / play.kotl.in before posting question here?
AM
I mean, it doesn't sound that hard to try it yourself, does it?