Или класс

У меня просто флешбеки от оду, где вся логика в моделях и это очень стремно

Логика самой модели может быть в модели

Ну, а бизнес-логика?

Часть бизнес логики

Которая затрагивает модель и, например, одну ее ссылку)

Это бы я не стал

Или скажем если у меня на один сервис с кучей кода аж одна модель, но штук 5 сервисов

Сервис который ставит модельки в очередь, сервис который слушает очередь, сервис валидации этих моделек и так далее)

Ну норм

А так все было бы в одной этой модели и было бы стремно :) Так что я обычно стараюсь ничего в модель не пихать, кроме логики работы с данными)

Функции в нем мокнуть)

А если тебе понадобится в коде два инстанса сервиса, но с разными бэкендт.

Ну, тут у меня уже будет DI нормальный. Пока что у меня такой подход только если объект всегда нужен только один

Ну вот у меня сейчас прилетел проект, в котором об этом не думали

И мне надо бэкенд заменить

Ну, похоже в далеком будущем кто-то будет меня ненавидеть)

Ну, тут у меня уже будет DI нормальный. Пока что у меня такой подход только если объект всегда нужен только один

лучше проектировать исходя из позиции, что объектов всегда может быть много и все юзать разные реализации зависимостей

главное палку не перегнуть, иначе можэно инжектить всё вообще

Как в ангуляре)

вот у меня щас код, который парсит и нормализует входные параметры занимается тем, что формирует сразу код для базы. А код, который парсит ответ базы сразу добавляет туда данные из кэша

а мне надо базу только заменить.

а парсинг входных данных и работу скэшами оставить

“база” - условно

Ну, такие штуки в своей orm, я таки добавил. Правда нельзя несколько бд использовать сразу, но это просто сложно сделать)

ну у меня не ORM, у меня щас Elasticsearch в качестве бэкенда

появился

от ОРМ толку ноль было бы

ну у меня не ORM, у меня щас Elasticsearch в качестве бэкенда

Я в итоге просто в основном потоке через цикл проверял окончена работа других потоков или нет.

Я в итоге просто в основном потоке через цикл проверял окончена работа других потоков или нет.

thread.join отменили?

Там вложенные потоки есть.

омг

А как? Подскажи.

ну то есть если у тебя кто-то запустил потоки, он пусть и ждет их завершения

а главный ждет его

ну либо общую waitgroup какую-то сделать

хз что там в питоне

Я что то типа флагов расставил

Бля, но вот с thread.join() хз. Вроде говорят его чуть ли не обязательно ставить. Но я хз как.

просто join() блокирует твой текущий поток, пока дочерний не завершится

ну то есть не дочерний, а для которого ты вызвал джойн

Это я знаю. Он обязательный или нет?

вроде нет

уфф)

но то, что ты сделал попахивает костылями

есть же condition variable например

хотя хз что у тебя там за код

Никита Бутов будет жить. Поприветствуем!

хотя хз что у тебя там за код

Потом на github закину. Однако: нужно одновременно анализировать несколько соцсетей и кучу отдельных факторов. join здесь не очень подходит.

может тебе больше подходит ThreadPoolExecutor?

хз что значит “анализировать” и "одновременно"

Например, искать в комментариях слова

Сразу для нескольких групп и соцсетей

сразу и одноверменно - разные вещи

Почему?

звучало как будто надо обязателньо проверять паралелльно. И нельзя сначала одну, а потом сразу другую

ладно, это уже софистика

Например, искать в комментариях слова

Тебе надо сначала собрать данные, потом уже анализировать. Слона надо кушать по частям. Собрал, подготовил данные, запустил анализ

А вот это здравая мысль. Пойду рефакторить.

да можно и сразу анализиторать, но это должны быть независимые части

Всмысле части?

прям части проги

анализтор не должен знать о парсере и наоборот

да можно и сразу анализиторать, но это должны быть независимые части

Да, я подразумевал, что эту цепочку можно независимо для каждого источника данных делать.

анализтор не должен знать о парсере и наоборот

Это если писать чисто ООП код. Я стараюсь комбинировать.

Это если писать чисто ООП код. Я стараюсь комбинировать.

Ты что-то путаешь. ООП и процедурный подход не имеют отношения к этому никакого

@DEADorHIRED будет жить. Поприветствуем!

оффтопик: Kafka же не по AMPQ работает?

Привет! Что должен знать разраб, который работает с Voip Какие бибилитеки, стеки, технологии, что-то еще Для питона и перла

Ты что-то путаешь. ООП и процедурный подход не имеют отношения к этому никакого

Мне показалось что он утверждает "Нужно мыслить объектно"

Привет! Что должен знать разраб, который работает с Voip Какие бибилитеки, стеки, технологии, что-то еще Для питона и перла

Sip, webrtc и забыть про перл

Мне показалось что он утверждает "Нужно мыслить объектно"

Смысл в том, чтобы разделить обязанности между разными частями кода.

ага

Ну я делаю это при помощи функций.

Тебе надо сначала собрать данные, потом уже анализировать. Слона надо кушать по частям. Собрал, подготовил данные, запустил анализ

ничего))) скоро придет к этому

оффтопик: Kafka же не по AMPQ работает?

нет

совсем нет

Как мне это передать в Python

мм

get_attribute('placeholder')

совсем нет

спасиб. я тут пытаюсь по конфигам понять с какими частям инфраструктуры работает сервис

value это уже другой аттрибут

value это уже другой аттрибут

Я понял,спасибо

Ребят а список и связанный список это одно и то же?

Я понял,спасибо

пожалуйста

Ребят а список и связанный список это одно и то же?

как правило

список это такой концептуально массив куда можно вставлять в середину, и вначало, без переписи всего

а связанный список это конкретная реализация списка

реализуется как связный список, или двойной

иногда двойной - где связи в две стороны

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

иногда еще хитрее - в зависимости от нужды

арагаер прав

питоновские например идут блоками

но это все понты