Интерфейс абстрактной фабрики в вашем случае - требование наличие метода create. Он имеет смысл, потому что мы можем сказать "вот сюда передайте любой объект с методом create". А как вы собираетесь описывать интерфейс для фабричного метода у меня вызывает вопрос, ведь в основном фабричный метод используется внутри того же класса (см. паттерн шаблонный метод)
Sorry, перечитал внимательно, фабричные методы на месте, но как-то впепремешку с фабриками. Вы там ещё и интерфейс для фабричных методов предлагаете и промпт у вас по запросу фабричного метода абстрактную фабрику выдал.
По моему личному опыту ИИ-тексты отличаются поразительно низким количеством полезной информации на единицу контента. Бывает читаешь, читаешь, вроде интересно, а что прочитал - непонятно. Три раза одну мысль перевернули по разному, досыпали несвязанных фактов, пропустили логические цепочки, никаких выводов или деталей, позволяющих эти выводы сделать самим. Конечно, так же пишут и некоторые копирайтеры, но это не в плюс к ним.
exec-кодогенерация не меняет подход к созданию объектов, она позволяет делать инайлнинг, вырезание веток и разворачивание циклов.
Условно, до кодгена был такой код
res = cls(*(container.get(d) for d in deps))
if cached:
cache[cls] = res
то, имея cached=False, а deps=[int, str, A], мы можем вырезать иф, убрать распаковку и сгенерировать
res = cls(container.get(int), container.get(str), container.get(A))
Резвол асинк зависимостей в dishka есть, то я бы рекомендовал с этим быть осторожнее. С большой вероятностью (вероятно не всегда), если вы делает async-вызов при создании ресурса, вы смешиваете бизнес логику и просто получение зависимости. При этом я понимаю, что избежать async вызова при финализации ресурса будет сложнее
А, ну я всегда рассматривал transient как "костыль", которым никто не пользуется, ведь scoped объекты ничем не хуже, зато точно можно переиспользовать в скоупе. Надо будет повнимательнее посмотреть на ваш код, вызвана скорость отсутствием фич или конкретными механиками, уж действительно быстро вышло
Я в dishka генерирую код на python и через exec преобразую. Это позволяет вырезать всякие ветки и разворачивать циклы. Например, так нет огранения на количество параметров функции (я вижу у вас отдельно расписаны варианта до 4)
По моему опыту, компиляция всего графа в одну функцию не очень хорошо ложится на кэширование/обработку ошибок и прочее. Функции становятся гигантскими, код грязным и прочее оно тормозит уже на этом этапе.
Я компилирую каждую обертку над конструктором, не весь граф. Это всё ещё работает очень быстро и не лишает вас других фич, которых можно напридумывать миллион.
Вижу что вы сравниваете скорость с wireup и dependency-injector, а с dishka не пробовали?
Не работает, если в приложении предполагается конкурентное использование БД. А это часто деталь реализации, которая если есть хотя бы в одном месте приложения, то значит может встретиться где угодно.
На всякий случай, я тут рылся по источникам и пришел к выводу что разделение конкурентности и параллелизма именно таким образом - это идея Роба Пайка и больше нигде не встречалась раньше. Тот же Таненбаум вполне юзает их как синонимы. Когда я учился в школе, использовались термины "истинная параллельность" и "псеводпараллельность" для тех случаев когда важно было уточнить эту разницу.
Ну во-первых, он упоминался в посте и какое-то ощутимое количество юзеров всё таки есть. Во-вторых, 40 issue, из которых большая часть - идеи по развитию - это не очень большое число. В третьих, проекту несколько лет, он давно прошел стадию активного наращивания фич, че там коммитить каждый день? В четвертых, кажется для кейса комментатора выше как раз неплохо подошло бы
Да, я не понимаю как вы собираетесь использовать интерфейс при реализации паттерна фабричный метод
Интерфейс абстрактной фабрики в вашем случае - требование наличие метода
create. Он имеет смысл, потому что мы можем сказать "вот сюда передайте любой объект с методом create". А как вы собираетесь описывать интерфейс для фабричного метода у меня вызывает вопрос, ведь в основном фабричный метод используется внутри того же класса (см. паттерн шаблонный метод)Sorry, перечитал внимательно, фабричные методы на месте, но как-то впепремешку с фабриками. Вы там ещё и интерфейс для фабричных методов предлагаете и промпт у вас по запросу фабричного метода абстрактную фабрику выдал.
Я может невнимательно читал, но не вижу в статье фабричных методов. Везде отдельный класс-фабрика
Но ведь Factory и Factory Method - это два разных паттерна
Взять растения с разной хиральностью и вот борьба за солнечный свет
Пол Андерсон "Звездный торговец"
По моему личному опыту ИИ-тексты отличаются поразительно низким количеством полезной информации на единицу контента. Бывает читаешь, читаешь, вроде интересно, а что прочитал - непонятно. Три раза одну мысль перевернули по разному, досыпали несвязанных фактов, пропустили логические цепочки, никаких выводов или деталей, позволяющих эти выводы сделать самим. Конечно, так же пишут и некоторые копирайтеры, но это не в плюс к ним.
exec-кодогенерация не меняет подход к созданию объектов, она позволяет делать инайлнинг, вырезание веток и разворачивание циклов.
Условно, до кодгена был такой код
то, имея
cached=False, аdeps=[int, str, A], мы можем вырезать иф, убрать распаковку и сгенерироватьРезвол асинк зависимостей в dishka есть, то я бы рекомендовал с этим быть осторожнее. С большой вероятностью (вероятно не всегда), если вы делает async-вызов при создании ресурса, вы смешиваете бизнес логику и просто получение зависимости. При этом я понимаю, что избежать async вызова при финализации ресурса будет сложнее
Асинкио таску можно потом когда-нибудь заэвейтить и получить результат, а тут.. увы
А, ну я всегда рассматривал transient как "костыль", которым никто не пользуется, ведь scoped объекты ничем не хуже, зато точно можно переиспользовать в скоупе. Надо будет повнимательнее посмотреть на ваш код, вызвана скорость отсутствием фич или конкретными механиками, уж действительно быстро вышло
Я в dishka генерирую код на python и через exec преобразую. Это позволяет вырезать всякие ветки и разворачивать циклы. Например, так нет огранения на количество параметров функции (я вижу у вас отдельно расписаны варианта до 4)
По моему опыту, компиляция всего графа в одну функцию не очень хорошо ложится на кэширование/обработку ошибок и прочее. Функции становятся гигантскими, код грязным и прочее оно тормозит уже на этом этапе.
Я компилирую каждую обертку над конструктором, не весь граф. Это всё ещё работает очень быстро и не лишает вас других фич, которых можно напридумывать миллион.
Вижу что вы сравниваете скорость с wireup и dependency-injector, а с dishka не пробовали?
а потом думаешь - а как теперь подождать после запуска, как получить её результат? а как узнать что функция упала с паникой?
Не работает, если в приложении предполагается конкурентное использование БД. А это часто деталь реализации, которая если есть хотя бы в одном месте приложения, то значит может встретиться где угодно.
Как насчет drop database + create database .. TEMPLATE? может быть быстрее транкейта
На всякий случай, я тут рылся по источникам и пришел к выводу что разделение конкурентности и параллелизма именно таким образом - это идея Роба Пайка и больше нигде не встречалась раньше. Тот же Таненбаум вполне юзает их как синонимы. Когда я учился в школе, использовались термины "истинная параллельность" и "псеводпараллельность" для тех случаев когда важно было уточнить эту разницу.
Ну кстати, а не сталкивались с отличиями поведения того же postgresql/mysql между версиями?
Стало интересно, а код где храните?
Ну во-первых, он упоминался в посте и какое-то ощутимое количество юзеров всё таки есть. Во-вторых, 40 issue, из которых большая часть - идеи по развитию - это не очень большое число. В третьих, проекту несколько лет, он давно прошел стадию активного наращивания фич, че там коммитить каждый день? В четвертых, кажется для кейса комментатора выше как раз неплохо подошло бы
Тогда зачем вы вводите в заблуждение, давая ссылки на хостинг исходного кода (гитхаб)?