Вопрос в сторону, а зачем могут понадобится свои Task like типы? Немогу представить большую абстракцию, чем Task, видимо нужна меньшая только зачем? Зачем различать Task и? Или это только чтобы генерик параметр «скрыть»?
IoC контейнер.
Не всегда проще но никогда не просто.
1) Ломается стройность API. Видно на пример EF Core. Вместо того чтобы создать контекст и передать в конструктор параметры. Создаешь контекст, достаешь контейнер и параметры пихаешь в контейнер. Хорошо когда есть и контйнер и конструктор (передача по стеку). А значит не просто.
2) Бардак вылезает из других мест, начинаются всякие per thread, xml configuration. И дебаг значительнос сложнее.
Я использую и IoC контейнер (получить конфиграцию в «юзер коде», но это может быть просто функция `Resolve` передаваемая по стеку).
И когда удобней переменная в глобальной области видимости, это значит что удобней переменная в глобальной области видимости. Никто не передает Math.Round через DI.
Выделить весь текст, удалить, смотреть на белый экран. Вы избавились от захардкоженных зависимостей.
Да моя позиция видимо такая же как и ваша все способы хороши. Чтобы не хардокодить можете сделать синглетон с тем парметром который иначе пришлось бы хардкодить, можете передавать параметр по стеку до всех мест использования, можете создать врап-функции (такие врапы будут на каждом вызове или по разу лезь за параметром в конфигурацию), а можете сгенерировать такой врап и выставить ее синглетоном в глобальной области видимости. Никакой разницы.
любую кодогенерацию ран тайм. вы просто не отлечите статический метод, от неизменяемой статической переменной с указателем на сгенерированную функцию (в языке в котором поддерживаются неизменяемые статические перменные и кодогенерация рантайм).
Ну так а чем вам условная СonfigurableMath.Round (синглетон делегат/функция, сгенерированная рантайм при первом использовании из параметров) хуже условного Math.Round (статический метод) объяснит кто-нибудь?
Если ситуация не знакома и вычурна разирсую: функция может быть сложнее, например сериализации (не потоковая, а именно конструируется проход по полям так что сериализация вообще без reflection, так быстрее потоковой на процентов 50-20)? Почему рантайм а не сохранить сгенерированную функцию в файл? Не надо управлять кодом.
«глобальное состояние» — нет такого термина. есть состояние и есть переменная в глобальной области видимости. синглтон это неизменяемая переменная в глобальной области видимости.результатом борьбы с синглетонами отвратительные догматеры которые делают стойку на самые примитивные вещи. Напримр. Переменная может быть и функцией. Math.Round(0.3333, 2) — это еще синглетон, но ничего не мешает создать динамически (через eval, expression trees etc) функцию-синглетон СonfigurableMath.Round(0.3333) таким образом что парметр «2» берется из конфигурации и делается вызов в Math.Round(0.3333, 2). Ну и чем СonfigurableMath.Round хуже Math.Round?
Cпасибо. Это круто, многих звездочек в ГитХабе достойно.
А можете в readme.md показать все с обвязкой в Startup.сs (Microsoft.AspNetCore), т.е. как вы переправляете запросы типа http://MyService/OData/Orders?$select=Name на ваш обработчик-parser? Чтобы понять время жизни объектов.
Да как бы это ссылка на источник, а не определение. И определение у GoF если я правильно понял дается через описание. А в таком случае будут точки зрения что «плохой» синглетон в описании GoF является частным случаем «приличного» немутабильного, объекта/функции с циклом жизни «синглтон», доступного через глобальную область видимости во время компиляции (для удобства).
Вы пишите: «цикл жизни „синглтон“ — не путать с паттерном!»… Такая позиция — позиция глухая. Одна сторона будет и далее использовать немутабильные, объекты/функции с циклом жизни синглтон (иногда даже давая им идентификаторы глобальной видимости времени компиляции), и называть их «синглтонами», а вы будете критиковать свои другие «синглтоны» (данные в определениях «банды четырех») и стороны не сойдутся.
Вы говорите «У синглтона есть глобальная точка доступа по определению, а не просто какая-то ссылка на объект». Не понимаю, что это значит, и что из этого следует, ведь ссылка на статический метод (или если хотите идентификатор статического метода, или идентификатор ссылки на метод) это тоже «глобальная точка доступа», да и не статический метод это тоже «глобальная точка доступа» (напр. в таблице виртуальных методов).
Но в результате надеюсь я вас понял, вы против неявных параметров и за DI. Однако и тут мне не понятно противопоставление синглетона и DI, ведь любой IoC контейнер (т.е. реализация DI) можно сконфигурировать на возвращение синглетона.
Не подумайте что я цепляюсь. Просто я стал понимать синглетон диалектически («нет ничего неизменяемого, но когда всё кругом переменные — очень не уютно»). И потому категорические суждения мне интересны, как возможность проверить собственную правоту.
Не понял про «параметризируется», поскольку в моем понимании «ссылка на функцию» и «ссылка на объект» это одно и тоже. Объект т.е. синглетон-объект это такая функция. Разве нет? Ну есть у объекта три метода, значит это функция возвращающая три метода.
Не понял про «подменяется», поскольку синглетон можно передавать в функцию и явно, через параметры.
Вообще это две разные проблемы: неявная передача параметров (может быть и не static индентификаторов даже) и объекты создаваемые при первом обращении и далее существующие в единственном числе в течении жизни аппликации (опять же могут быть и не через static определенные).
Хочу спросить и уточнить, что такое «имея EntityFramework… подключаю OData»? Создаете сервис унаследованный от EntityFrameworkDataService? Его нет в EF Core.
Не правильно такими тяжелыми (специфическими) примерами иллюстрировать такой сильный (общий) тезис.
Чем сингелтон отличается от «ссылки на функцию»? Ситуация: вы используете динамическую функцию зачем ее пересобирать каждый раз при переиспользовании?
Интересно что такое «лендинг-магазин»?
Можно вас подробней указать требования. Что такое «полнофункциональная корзина»? Клиент, создав заказ отправляет вам письмо и это все? У вас есть список заказов с их статусами, если да то в каком виде? Есть ли проверка, что товар в наличии, может быть доставлен в данный регион, и подсчет цены доставки, есть ли оплата?
Не всегда проще но никогда не просто.
1) Ломается стройность API. Видно на пример EF Core. Вместо того чтобы создать контекст и передать в конструктор параметры. Создаешь контекст, достаешь контейнер и параметры пихаешь в контейнер. Хорошо когда есть и контйнер и конструктор (передача по стеку). А значит не просто.
2) Бардак вылезает из других мест, начинаются всякие per thread, xml configuration. И дебаг значительнос сложнее.
Я использую и IoC контейнер (получить конфиграцию в «юзер коде», но это может быть просто функция `Resolve` передаваемая по стеку).
И когда удобней переменная в глобальной области видимости, это значит что удобней переменная в глобальной области видимости. Никто не передает Math.Round через DI.
Да моя позиция видимо такая же как и ваша все способы хороши. Чтобы не хардокодить можете сделать синглетон с тем парметром который иначе пришлось бы хардкодить, можете передавать параметр по стеку до всех мест использования, можете создать врап-функции (такие врапы будут на каждом вызове или по разу лезь за параметром в конфигурацию), а можете сгенерировать такой врап и выставить ее синглетоном в глобальной области видимости. Никакой разницы.
Если ситуация не знакома и вычурна разирсую: функция может быть сложнее, например сериализации (не потоковая, а именно конструируется проход по полям так что сериализация вообще без reflection, так быстрее потоковой на процентов 50-20)? Почему рантайм а не сохранить сгенерированную функцию в файл? Не надо управлять кодом.
А можете в readme.md показать все с обвязкой в Startup.сs (Microsoft.AspNetCore), т.е. как вы переправляете запросы типа http://MyService/OData/Orders?$select=Name на ваш обработчик-parser? Чтобы понять время жизни объектов.
Но в результате надеюсь я вас понял, вы против неявных параметров и за DI. Однако и тут мне не понятно противопоставление синглетона и DI, ведь любой IoC контейнер (т.е. реализация DI) можно сконфигурировать на возвращение синглетона.
Не подумайте что я цепляюсь. Просто я стал понимать синглетон диалектически («нет ничего неизменяемого, но когда всё кругом переменные — очень не уютно»). И потому категорические суждения мне интересны, как возможность проверить собственную правоту.
Не понял про «подменяется», поскольку синглетон можно передавать в функцию и явно, через параметры.
Вообще это две разные проблемы: неявная передача параметров (может быть и не static индентификаторов даже) и объекты создаваемые при первом обращении и далее существующие в единственном числе в течении жизни аппликации (опять же могут быть и не через static определенные).
Чем сингелтон отличается от «ссылки на функцию»? Ситуация: вы используете динамическую функцию зачем ее пересобирать каждый раз при переиспользовании?
Можно вас подробней указать требования. Что такое «полнофункциональная корзина»? Клиент, создав заказ отправляет вам письмо и это все? У вас есть список заказов с их статусами, если да то в каком виде? Есть ли проверка, что товар в наличии, может быть доставлен в данный регион, и подсчет цены доставки, есть ли оплата?
Микрософт ставит на то что в его стеке и EAI и SOA будут заабстрагированы микросервисами.