Size: a a a

Android Architecture

2020 September 24

RC

Roman Chumachenko in Android Architecture
Ребят, подскажите такую штуку, есть два разных протоколо ManagerA и ManagerB, каждый занят своими делами. Так же оба два с текущим стеком имеют состояние запущен/остановлен. Попытался описать последнее через отдельный протокол в таком виде:
Node {
     val isOnline: BehaviorSubject<Boolean>
     fun start(): CompletableSubject
     fun stop(): CompletableSubject
}
Проблема в том, что ManagerA не требует ничего для старта, тогда как ManagerB требует некоторые примитивы получать для старта и возможность остановить работу и заменить при повторном старте эти значения.
Мне в голову приходит такой вариант: Node<T : Args>, где Args будет sealed class, наследник которого может нести от 0 до Н-штук параметров. Это ведь костыль, да?
источник

AD

Aleksey D. in Android Architecture
Roman Chumachenko
Ребят, подскажите такую штуку, есть два разных протоколо ManagerA и ManagerB, каждый занят своими делами. Так же оба два с текущим стеком имеют состояние запущен/остановлен. Попытался описать последнее через отдельный протокол в таком виде:
Node {
     val isOnline: BehaviorSubject<Boolean>
     fun start(): CompletableSubject
     fun stop(): CompletableSubject
}
Проблема в том, что ManagerA не требует ничего для старта, тогда как ManagerB требует некоторые примитивы получать для старта и возможность остановить работу и заменить при повторном старте эти значения.
Мне в голову приходит такой вариант: Node<T : Args>, где Args будет sealed class, наследник которого может нести от 0 до Н-штук параметров. Это ведь костыль, да?
да, боль
источник

S

Singular in Android Architecture
Roman Chumachenko
Ребят, подскажите такую штуку, есть два разных протоколо ManagerA и ManagerB, каждый занят своими делами. Так же оба два с текущим стеком имеют состояние запущен/остановлен. Попытался описать последнее через отдельный протокол в таком виде:
Node {
     val isOnline: BehaviorSubject<Boolean>
     fun start(): CompletableSubject
     fun stop(): CompletableSubject
}
Проблема в том, что ManagerA не требует ничего для старта, тогда как ManagerB требует некоторые примитивы получать для старта и возможность остановить работу и заменить при повторном старте эти значения.
Мне в голову приходит такой вариант: Node<T : Args>, где Args будет sealed class, наследник которого может нести от 0 до Н-штук параметров. Это ведь костыль, да?
хз может сделай проверку на null, если null то start выведет что - то или вообще ничего не сделает.
источник

S

Singular in Android Architecture
тебе же start для ManagerA все равно не нужен верно я понял тебя?
источник

RC

Roman Chumachenko in Android Architecture
Все равно бред, потому что там параметры довольно специфичные - ManagerA вообще не должен знать про какие-то threadKey, folderName и прочую дичь
источник

S

Singular in Android Architecture
А если ManagerA и B передавать обертку над этими данными
источник

RC

Roman Chumachenko in Android Architecture
Singular
тебе же start для ManagerA все равно не нужен верно я понял тебя?
То-то и оно, что нужен старт/стоп и стейт для обоих протоколов, просто у каждого он свои зависимости может требовать
источник

RC

Roman Chumachenko in Android Architecture
Singular
А если ManagerA и B передавать обертку над этими данными
Вот я думал про обертку в виде sealed class)
источник

S

Singular in Android Architecture
ну хз, или обертка или отдельные интерфейсы, что считаю бредом
источник

RC

Roman Chumachenko in Android Architecture
В итоге просто разделил их на ManagerANode и ManagerBNode, у каждого свои параметры будут
источник

S

Singular in Android Architecture
или как говорил булеан. Ничего больше в голову не приходит)
источник

S

Singular in Android Architecture
Roman Chumachenko
В итоге просто разделил их на ManagerANode и ManagerBNode, у каждого свои параметры будут
Ну пока их мало, можно и так)
источник

RC

Roman Chumachenko in Android Architecture
Singular
Ну пока их мало, можно и так)
Ну честно, что у них общего - старт и состояние, это можно вынести в какой-то протокол BaseNode, а старт у каждого менеджера писать свой, потому что зависимости разные будут
источник

S

Singular in Android Architecture
А вообще sealed с Genericoм как раз вариант если их много
источник

AB

Alex Bieliaiev in Android Architecture
Почему не сделать класс Parameters не sealed
источник

AB

Alex Bieliaiev in Android Architecture
Какую проблему решает sealed?
источник

RC

Roman Chumachenko in Android Architecture
Alex Bieliaiev
Почему не сделать класс Parameters не sealed
Окей, пусть не запечатанные, все равно решение такое себе - нужно в start<T : Params>(param: T) либо передавать заглушку в духе NoArgs: Params(), либо сделать аргумент наллабл и всюду чекать на налы
источник

AB

Alex Bieliaiev in Android Architecture
Согласен, что null передавать не стоит
источник

AB

Alex Bieliaiev in Android Architecture
Но пустые параметры вполне себе
источник

RC

Roman Chumachenko in Android Architecture
Alex Bieliaiev
Но пустые параметры вполне себе
В смысле заглушку, да?
источник