LINUX.ORG.RU

Как избавиться от псевдоколлбеков?

 , ,


0

4

Доброе утро, благородные доны.

Сегодня вопрос такой: пусть есть класс Foo, который в одном из методов создает объект класса Bar. Перед этим Foo создает окружение, в котором Bar исполняет связанную с ним логику, и поэтому в целях инкапсуляции этой самой логики хочется, чтобы Foo передавал в Bar this, а тот уже дергал нужные ему (публичные) методы.

Но тогда получается, что все это напоминает коллбеки по своей конструкции (в стеке бутерброд получается из методов Foo, Bar и снова Foo), а коллбеки мне не нравятся как концепция. Поэтому скажите, пожалуйста, как можно более чисто такую хрень спроектировать? А, еще ситуация осложняется тем, что в одном и том же месте такой паттерн придется несколько раз применить вложенным образом (т. е. Bar создает новые объекты, которые таким же макаром будут дергать его методы, и т. д.), и от этого тошнит еще больше.

Спасибо.

Какую задачу ты _изначально_ хочешь решить?

GoodRiddance
()

коллбеки мне не нравятся как концепци

Если тебе не нравятся колбеки как концепция (то есть ни в каком завуолированном виде)...

...то наверно тебе подойдёт способ программирования через копипаст :-)

user_id_68054 ★★★★★
()

Делаешь пандорический захват, лифтишь в монаду, потом строишь рекурсивную схему (здесь подойдёт зигохистоморфный препроморфизм ) как монадический трансформер из категории эндофункторов, и метациклически вычисляешь результат. Любой второкурсник справится. А если делать на анафорических лямбдах — так задачка вообще на пять минут.

anonymous
()
Ответ на: комментарий от user_id_68054

Если тебе не нравятся колбеки как концепция (то есть ни в каком завуолированном виде)... то наверно тебе подойдёт способ программирования через копипаст :-)

наиболее завуолированно получится скрыть колбэк — если второй объект будет создан на основе наследования-или-подмешивания.

user_id_68054 ★★★★★
()

Засунь свою эстетику себе сам знаешь куда. Коллбэки — совершенно нормальный подход.

Miguel ★★★★★
()

в стеке бутерброд получается из методов Foo, Bar и снова Foo

о боже! страх-то какой!! [/сарказм]

ну значит разбей Foo на два разных класса.

код станет всё менее читаемый (чем больше всяких сущностей в нём начнёт появляться), но зато для тебя это будет казаться более эстетическим :-)

вот если поглядеть на исходный код какого-нибудь интерпрайз-стайл-фреймворка — то там кака раз миллион мелких сущностей и ни чего не понять из-за этого с ходу

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)

а коллбеки мне не нравятся как концепция

хрень спроектировать

ситуация осложняется

тошнит еще больше

Пц у людей проблемы.

Pavval ★★★★★
()
Ответ на: комментарий от Deleted

Я подумал об этом - у меня и так многопоточность и очереди сообщений уже есть, но не хотелось бы прям повсюду их пихать. Но раз других вариантов нет, видимо, придется. Спасибо:)

WizardOfOz
() автор топика
Ответ на: комментарий от Pavval

Miguel

user_id_68054

Да, я понимаю, что вопрос может показаться идиотским, но речь о моем just4fun проекте, который я в свое удовольствие пилю в свободное время, и который гарантированно никому и никогда не понадобится, даже если я каким-то чудом его допилю, поэтому я не вижу причин не попытаться сделать все правильно:)

WizardOfOz
() автор топика
Ответ на: комментарий от WizardOfOz

Я подумал об этом - у меня и так многопоточность и очереди сообщений уже есть, но не хотелось бы прям повсюду их пихать. Но раз других вариантов нет, видимо, придется. Спасибо:)

Вот это ты говна наешься на ровном месте. Передать сообщение, и получить его позже, когда всё уже (контекст) вокруг поменялось - это же классические проблемы. Я целые проекты знаю, полностью написанные вокруг этого типа бага:) Уж лучше коллбеки.

Pavval ★★★★★
()

По-моему, ты слегка попутал причину и следствие. Это не дёргание переданного API похоже на коллбэки, а наоборот, коллбэки - это костыль для имитации передачи сообщений в языках без ООП. И в языках с классами оно выглядит вполне естественно.

hobbit ★★★★★
()
Ответ на: комментарий от Pavval

Я к тому, что решение в принципе есть. Хуже или лучше оно болезни, спорить не возьмусь.

P.S. Ан нет, ОПу не подойдёт, там ненавистные callback'и используются всё равно.

GoodRiddance
()

Чем это плохо? Если ты явно передаешь, то у тебя видна явная зависимость между объектами. Куда хуже (для понимания и поддержки), когда есть общий пул данных уровня синглетона.

Kuzy ★★★
()
Ответ на: комментарий от hobbit

Как раз наоборот. Значительная часть ООП — это костыль для имитации замыканий, когда нужен обычный коллбэк, но в нём — дополнительные переменные.

Miguel ★★★★★
()

Омг, человек спрашивает как грамотно и красиво определить интерфейсы между двумя классами в однопоточном коде, а ему тут советуют многопоточность и обмен сообщениями *facepalm*

Лорчую коллбэки

kravich ★★★★
()
Последнее исправление: kravich (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.