AD
Тяжело это дебажить
Size: a a a
2020 August 17
か
Я может тупой, но я только что радостно скомпилировал интерфейс с двумя методами, перегруженными по типу аргумента. Что не так?
Я тоже не совсем понял проблему
Делаешь общий интерфейс для А и B, запиливаешь туда два перегруженных метода
Делаешь общий интерфейс для А и B, запиливаешь туда два перегруженных метода
DC
humanoid
Код в студию пожалуйста
interface A{
String handle(Integer a);
String handle(String a);
}WD
Тогда читайте задачу. У вас не 2 варианта, а n. Который ещё и динамическим может быть.
h
Тогда читайте задачу. У вас не 2 варианта, а n. Который ещё и динамическим может быть.
Вот - да
h
interface A{
String handle(Integer a);
String handle(String a);
}Поэтому такое не подходит
WD
Я бы предложил делать интерфейс Handler<View,Provider>.
DC
humanoid
В Java нелья получается вывести интерфейс для двух классов (А и B), чтобы например положить их в общих лист и затем вызывть handle?
class One{}
class Two{}
class A{
String handle(One one){
return "A-One";
}
String handle(Two one){
return "A-Two";
}
}
class B{
String handle(One one){
return "B-One";
}
String handle(Two one){
return "B-Two";
}
}Читаю задачу, класса было два
DC
XY problem в общем, понял
WD
Вопрос в том, у тебя каждая вьюха должна каждого провайдера обслуживать? Или могут отсутствовать?
WD
Ну да.
h
Вопрос в том, у тебя каждая вьюха должна каждого провайдера обслуживать? Или могут отсутствовать?
Не обязательно
h
Если провайдера для форомочки/view нет, то компайл еррор
WD
Ты себе противоречишь. Если не обязательно, т.е. могут отсутствовать пары view-provider, то вариант выше тебе подходит. Если же обязаны быть все связи, то имеет смысл делать 1 общий интерфейс с методами под каждую вьюху, либо наоборот, под каждого провайдера.
DC
Вообще в первом приближении самым разумным в рамках джавы решением кажется сделать енум с провайдерами, и по нему свитчиться
h
Вообще в первом приближении самым разумным в рамках джавы решением кажется сделать енум с провайдерами, и по нему свитчиться
Должно расширяться. Енум тут не подходит.
h
Ты себе противоречишь. Если не обязательно, т.е. могут отсутствовать пары view-provider, то вариант выше тебе подходит. Если же обязаны быть все связи, то имеет смысл делать 1 общий интерфейс с методами под каждую вьюху, либо наоборот, под каждого провайдера.
Ща - осмыслю
h
Я бы предложил делать интерфейс Handler<View,Provider>.
Смотри Handler<View,Provider> - тут проблема, что я не могу создать этот handler без указания сразу двух парамтеров в одном месте. А я хочу сначала положить в лист все Handler -ы c нужными View, а потом доставая из листа - давать еще и Provider