FG
я хочу создать класс внутри которого будет происходить запись звука,планирую сделать их саспенд функциями.это нормальная практика?)
Size: a a a
2021 June 01
TT
Подскажите, вот в котлин если не написать open, то не отнаследоваться. Не кажется ли это излишним и усложняющим разработку? Приходится тщательно все продумывать, а это не всегда возможно. Берешь либу чью-то и не отнаследующешься, если об этом заранее не подумали
TT
FG
благодарю
FG
могу я задать еще один вопрос?что бы работа происходила одновременно в двух разных потоках,мне следует создать два разных скоупа?
FG
в одном треде должна происходить запись звука,и передача стрима в определнный класс.а в другом треде использовать этот самый экзмп класса для определнных действий
TT
на каких потоках будет идти работа решает сам диспетчер. Просто выполнение двух разных функций на одном диспетчере приведет к выполнению их на разных потоках.
FG
то есть launch{ } и закинуть туда нужные мне методы?
DA
какой из вариантов лучше? есть какие-нибудь best practices по этому поводу в котлине?
DA
TT
ну да, только надо результат ланч хранить, это дефферед или джоба.
AL
That's the point. Чтобы твой класс был готов к расширению, ты должен приложить какие-то усилия. Если ты их приложил - разметить класс и конкретные функции в нём как open не составит труда. А если нет - класс не стоит расширять просто так.
FG
окей,ща пробну
AL
Без контекста непонятно, чего вообще хочется добиться. Если нету повода, то конечно городить всякие классы, абстрактные классы и так далее не нужно.
TT
а как же solid , open/close принцип, когда классы должны быть открыты для расширения или опять же, под этим подразумевается, что ты сам должен его открыть для расширения
TT
ну вообще справедливо, но часто бывает желание отнаследоваться в какой-то либе, от класса и переопределить его алгоритм..но увы, не продумал разработчик. И да, опять таки не убирать же все ограничения на случай плохого разработчика..не знаю..спорно все
AL
Если по солиду, то "и закрыты для модификации". Это даже в первую очередь скорее, нужно делать так, чтобы любой наследник не мог получить какого-то непредсказуемого поведения, которого неочевидно на основе исходного класса. Можно ли это сделать? Да. Нужно ли это делать? Не всегда.
DA
хочется сделать несколько очень похожих по смыслу и структуре функций, вот я и думаю стоит ли их явно объединять одним классом или нет?
TT
наверно стоит внести третий модификатор типо Я рискну, который вешается на свой класс, если отнаследовался от закрытого класса)
TT
ну вот я сильно хотел в игровом движке как то переписать алгоритм отталкивания от стен на плоскости, он был у них с багом, понятия не имею как они с ним жили и зачем. Но вышло только списать их код и отказаться от библиотеки)