BG Development Форуми -> Логически операции в RxJava поток

BG Development · За реклама · За контакти

Помощ

Търсене

Потребители

Календар

Правила

Здравей! ( Включване | Регистриране )

BG Development Форуми -> Програмиране -> Java/Kotlin

Страници: (2) 1 [2] ( Първото ново мнение )

Логически операции в RxJava поток

Абонирай се за темата | Изпрати адреса на темата на приятел | Принтирай темата

goro

Публикувано на: 21-02-2025, 13:53

Име:
Група: Потребител
Ранг: Активен

Мнения: 171
Регистриран на: 31.05.09

QUOTE (thrawn @ 21-02-2025, 13:06)

Тук става дума за принципен проблем. Не получаваш нищо в повече или по-малко. Просто подходът е различен.
В императивното програмиране сам си взимаш данните докато в реактивното чакаш някой да ти ги сдъвче и изплюе на готово

Да принципно е. И мисля, че по горе сам си си отговорил.

CODE

Основния момент тук е, че се въвежда терминът "реактивно програмиране" и съответно се почват някакви разпалени обяснения как if/else, for ... не бива да се ползват в контекстът на реактивното програмиране. Съответно почват да се появяват подобни тривиални проблеми (Може би, от липса на опит, знам ли. Затова и пуснах темата).

Та като се замисля, когато в java въведоха stream апи-то...
...
А причината за различните мнения е, че хората които са прекалено ентусиазирани от самото апи генерализират[B] докато хората с опит (може би) казват, че няма лошо да се ползва императивен стил на програмиране[/B] във функциите.

Догматизма и разни "разпалени обяснения как if/else, for" за мен противоречат на здравия разум.

п.п.
Благодаря за пояснението. За мен наистина е полезно. Като любител, съответно не познаващ добре нито терминологията нито професионалния жаргон, много пъти чета разни неща и дълго не вдявам за какво става въпрос. Докато отнякъде ми светне и се сетя че това за което чета съм го правил, просто не съм знаел как се казва...

thrawn	Публикувано на: 21-02-2025, 14:01
Име: Група: Потребител Ранг: Почетен член Мнения: 3733 Регистриран на: 17.01.17	Е, то и аз не съм програмист, така че сме двама

goro	Публикувано на: 21-02-2025, 15:02
Име: Група: Потребител Ранг: Активен Мнения: 171 Регистриран на: 31.05.09	Е... не си личи... За мен, най-важното в един инструмент е да е лаконичен, прост, ефективен и да ползва само онези части от даден език, за които има малка вероятност да отпаднат или да се промени функционирането им. (Примерно, преди години си писах един текст едитор и в няколко случая ползвах execCommand(). По него време метода беше експирементален. И изведнъж стана "deprecated". Слава Богу, едитора ми още работи, но...)

Bender++	Публикувано на: 22-02-2025, 14:34
Име: Група: Потребител Ранг: Редовен член Мнения: 568 Регистриран на: 18.04.21	Просто и четливо и Rxjava не могат да са в едно изречение. Няма смисъл да си губиш времето с това извращение. Ползвай greeen threads, али ако поради някаква причина не можеш - по-добре го пренапиши на golang отколкото да се мъчиш с тая шитня -------------------- Слава на Цар Путин! Долу украинските фашисти!

thrawn	Публикувано на: 22-02-2025, 15:56
Име: Група: Потребител Ранг: Почетен член Мнения: 3733 Регистриран на: 17.01.17	Под зелени нишки, имаш в предвид асинхронност въру една работна нишка? Като цяло, това не е някакъв проект по който работя сериозно. Просто си играя, за да видя за какво иде реч в края на краищата. За сега като цяло ми харесва възможността за синхронизация между отделните нишки която се получава на готово. Не че е проблем да го направиш и ръчно, но с тая библиотека става с два реда код. Пускаш задача в друга нишка (или където искаш) и резултатът ти идва в UI-а (или където го искаш) без особено нагъване, когато е готов. А най-хубавото е, че това върви и в андроид (а той, милинкия е претенциозен). Не ми харесва само фиксацията в това реактивно програмиране. Между другото, щото последните години ползвам основно FX, гледам че плъгина за FX не поддържа rxjava3 та си пуснах собствен scheduler който да изпълнява задачите на FX нишката. То реално само това ми трябва от него. Това мнение е било редактирано от thrawn на 22-02-2025, 15:58

RoYaL

Публикувано на: 06-04-2025, 19:34

Име:
Група: Потребител
Ранг: Старо куче

Мнения: 873
Регистриран на: 21.08.05

QUOTE (thrawn @ 21-02-2025, 08:45)

Генерирането на самия Observable обект не е интересно (спецификата, че става дума за web api). Емитнатите данни могат да са дори прости числа и да трябва да предприемем различно действие в зависимост от самото число.

Мисля, че тук решението ти е "polymorphism vs. conditionals" или иначе казано - да се измести прочитането на условността в нещо като фабрика (или по-скоро регистър), която продуцира стратегия. Да приемем, че се случва в контекста на някакъв IoC фреймуърк, или вътрешно имаш лесен начин да правиш dependency injection. От тази гледна точка, например имаш:

CODE

interface NumbersStrategy {

boolean supports( int num );

int execute( int num );
}

Като се хванах за примера с числата, но естествено можеше да е "ResponseStrategy" и да приема "HttpResponse". Съответно имаш някакви имплементации (в контекста на ResponseStrategy биха били - OK, Error, и т.н.):

CODE

class SelfMultiplicationEvenNumberStrategy implements NumbersStrategy {

boolean supports( int num ) {
return num % 2 == 0;
}

int execute( int num ) {
return num * num;
}

}

class DuplicationOddNumberStrategy implements NumbersStrategy {

boolean supports( int num ) {
return num % 2 != 0;
}

int execute( int num ) {
return 2 * num;
}

}

От тук ти трябва нещо, което ги събира всички възможни стратегии в едно и избира измежду тях:

CODE

record StrategyExecutorFacade(
NumbersStrategy strategy,
int num
) {

public int execute() {
return this.strategy.execute(num);
}
}

class NumberStrategyRegistry {

private final List<NumbersStrategy> strategies;

// constructor

public StrategyExecutorFacade choose( int num ) {
return new StrategyExecutorFacade(
this.strategies.stream().filter(s -> s.supports( num )).findFirst().orElseThrow(),
num
);
}

}

И сега в consuming code-a имаш:

CODE

service.map( number -> registry.choose(number) )
.map( facade -> facade.execute() )
.subscribe( resultingNumber -> System.out.println(resultingNumber) );

Long story short: Условията на if-а ти се събират в supports(...) метода на стратегиите. В крайна сметка не бягаш от тях, но ги изнасяш някъде другаде и това, което получаваш е:

Четимост в основния код, който се абонира за сървиса - твоите читатели на кода, виждат каквото трябва да видят - получаваме числа от сървис, намираме стратегия за тях, изпълняваме я, принтираме числата
С добре сетъпнат Dependency Injection просто трябва да добавиш нова стратегия за да заработят нещата, без да добавяш ново условие в съществуващия код. Кодът, който се абонира за сървиса остава непроменен.

Това мнение е било редактирано от RoYaL на 06-04-2025, 19:37

1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)

Потребители, преглеждащи темата в момента:

« Предишна тема | Java/Kotlin | Следваща тема »

Страници: (2) 1 [2]

BG Development Форуми -> Програмиране -> Java/Kotlin