Ну давайте решим простую задачу в функциональном стиле: пользователь вводит число N и потом N чисел, надо их отсортировать и вывети. Как это реализовать на Си без любых изменений переменных? Сортировку можете не писать, давайте её держать в голове как готовую (функция принимает массив, возвращает массив), ограничимся только вводом данных. Как это будет выглядеть на си в ФП стиле?
жизненный цикл зависимостей в DI контейнерах тоже может быть синглтоном.
Он так называется по тем же причинам что и паттерн синглтон, но это принципиально разные вещи. Вы возможно не поняли, но статья про паттерн синглтон, а НЕ про возможности DI-контейнеров
Под тем, что функция не синглтон я имел ввиду, что не любая функция существует в одном экземпляре. Функциональное программирование активно использует замыкания, поэтому там функции пересоздаются постоянно с разными состояниями. То, что в ООП выглядело бы как класс с методом и атрибутами-данными
Я не ФП программист, но мне казалось, один из основных принципов ФП - неизменяемые переменные. С этим у си немного так проблемы. Ну и гарантий оптимизации хвостовой рекурсии тоже нет, что ограничивается в применении определенных фп-алгоритмов
Хотите ли в тестах продолжнать использовать уже загрязненный кэш вместо создания нового объекта?
А не появится ли необходимость запустить два логических экземпляра объекта в одном процессе, чтобы у них были свои кэши? (3 года назад ботоделы меня убеждали что не нужно такое никогда, а потом у половины из них "мультиботы" в ходу оказались)
Про пул соединений тоже классика - сгодня он один, а завтра завезли CQRS и у нас два пула: на чтение и на запись.
Но я отвлекся, вопрос был: чем синглтон в этих случаях ЛУЧШЕ других подходов, а не почему он может прокатить в частном случае
Двухэтапное создание делается не от хорошей жизни. Это в целом вещь неочевидная и грозящая проблемами в духе "начали юзать до завершения второго этапа" или "надо везде проверить второй этап вызвали или нет", но иногда по другому ещё сложнее.
А как СУБД относится к такой вариабельности? Вы случайно не дали фронтендарм возможность сгенерировать 100 джойнов и не насоздавали 10000 индексов по всем комбинациям полей просто потому что "вдруг кому-то понадоибться"? Каждый раз когда я вижу graphql я боюсь такого исхода, как вы его изебгаете?
Открою секрет: если понять что делает код можно по обоим частям, то одна из них написана зря. Программисты стараются писать код так, чтобы он был понятен без комментариев.
Правильные абстракции призваны как раз улучшить читаемость. Они помогают понять как работает программа без изучения абсолютно всего кода. Отсутствие абстракций часто приводит к необходимости зазубрить весь код чтобы понять как работает небольшая его часть. Плохие абстракции делают и это недостаточным.
При этом я соглашусь, что добавление абстракций или дробление кода может ухудшить "отлаживатьмость" то есть поиск мест где были совершены ошибки, в частности если эти самые абстракции протекли.
собственно у меня ощущение, что с graphql мы жертвуем процессом дизайна апи и согласования требований - то есть экономим в краткосрочной перпективе чтобы потом было сложнее это всё поддерживать
Не обязательно будет. Я уже приводил пример необходимости двух пулов: для чтения (в реплики) и для записи (в мастер)
Ну давайте решим простую задачу в функциональном стиле: пользователь вводит число N и потом N чисел, надо их отсортировать и вывети. Как это реализовать на Си без любых изменений переменных? Сортировку можете не писать, давайте её держать в голове как готовую (функция принимает массив, возвращает массив), ограничимся только вводом данных. Как это будет выглядеть на си в ФП стиле?
Он так называется по тем же причинам что и паттерн синглтон, но это принципиально разные вещи. Вы возможно не поняли, но статья про паттерн синглтон, а НЕ про возможности DI-контейнеров
Под тем, что функция не синглтон я имел ввиду, что не любая функция существует в одном экземпляре. Функциональное программирование активно использует замыкания, поэтому там функции пересоздаются постоянно с разными состояниями. То, что в ООП выглядело бы как класс с методом и атрибутами-данными
Я не ФП программист, но мне казалось, один из основных принципов ФП - неизменяемые переменные. С этим у си немного так проблемы. Ну и гарантий оптимизации хвостовой рекурсии тоже нет, что ограничивается в применении определенных фп-алгоритмов
на си? без замыканий?
мы всё ещё про функциональное программирование говорим?
Не просто НЕ один коннект, но регулярно 2 пула коннектов появляется (на мастер и на реплики)
Простите, но между "вручную копировать" и "вручную искать где же юзается get_instance раньше чем надо" я выбираю первое. Это точно проблема?
Функции не синглтоны, потому что существуют замыкания.
Ну давайте подумаем.
Хотите ли в тестах продолжнать использовать уже загрязненный кэш вместо создания нового объекта?
А не появится ли необходимость запустить два логических экземпляра объекта в одном процессе, чтобы у них были свои кэши? (3 года назад ботоделы меня убеждали что не нужно такое никогда, а потом у половины из них "мультиботы" в ходу оказались)
Про пул соединений тоже классика - сгодня он один, а завтра завезли CQRS и у нас два пула: на чтение и на запись.
Но я отвлекся, вопрос был: чем синглтон в этих случаях ЛУЧШЕ других подходов, а не почему он может прокатить в частном случае
Двухэтапное создание делается не от хорошей жизни. Это в целом вещь неочевидная и грозящая проблемами в духе "начали юзать до завершения второго этапа" или "надо везде проверить второй этап вызвали или нет", но иногда по другому ещё сложнее.
Тут важно не путать скоуп "синглтон" в IoC-контейнерах и синглтон как паттерн. Статья о втором.
А проблема в чем?
А в чем профит того что он синглторн если он везде внедряется через DI? В чем отличие от не-синглтона?
А можно пример реально нужного случая? Тот, который по другому не решить (например через DI единственного экземпляра)
То есть, Мальвинские?
А как СУБД относится к такой вариабельности? Вы случайно не дали фронтендарм возможность сгенерировать 100 джойнов и не насоздавали 10000 индексов по всем комбинациям полей просто потому что "вдруг кому-то понадоибться"? Каждый раз когда я вижу graphql я боюсь такого исхода, как вы его изебгаете?
Открою секрет: если понять что делает код можно по обоим частям, то одна из них написана зря. Программисты стараются писать код так, чтобы он был понятен без комментариев.
SOLID вообще не требует DI, btw
Правильные абстракции призваны как раз улучшить читаемость. Они помогают понять как работает программа без изучения абсолютно всего кода. Отсутствие абстракций часто приводит к необходимости зазубрить весь код чтобы понять как работает небольшая его часть. Плохие абстракции делают и это недостаточным.
При этом я соглашусь, что добавление абстракций или дробление кода может ухудшить "отлаживатьмость" то есть поиск мест где были совершены ошибки, в частности если эти самые абстракции протекли.
собственно у меня ощущение, что с graphql мы жертвуем процессом дизайна апи и согласования требований - то есть экономим в краткосрочной перпективе чтобы потом было сложнее это всё поддерживать