Возможно ли реализовать подобное в C#/F# сейчас или в ближайшем будущем без использования dynamic?

var service = new StupidService()
.Smart()
.Useful();

ISmartService s1 = service;
IUsefulService s2 = service;

В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.

Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?

Почему не подходит контейнер — отсутствие проверок на этапе компиляции. Да, Resolve<IService> будет бросать исключения, если зависимости не были проинициализированы, но узнаем мы об этом только в рантайме.

Вроде, можно не выпендриваться и передавать именовпнные таплы. Но если об этом подумать, то и таплы не нужны — в одном месте зависимость разрешил, и тащишь ее через все слои вниз. Вот только там, где сейчас один контейнер появятся десятки аттрибутов или опять же скомбинированные хелпер-контейнеры. И это без масштабных нарушений ответственности, а они есть и будут есть.

Подумав немногл, понял, что просто неверно думаю о реализации IOC-контейнеров. У него должна быть возможность разрезолвить любой сервис без необходимости вручную задавать зависимости. В таком случае и проблемы не будет как таковой. Просто провайдер микросервисов... Это нужно обдумать.

Здравствуйте, LWhisper, Вы писали:


LW>В случае Extension-методов возникает проблема написания кода для всех возможных комбинаций интерфейсов.

LW>Вариант с рантайм-генерацией типов подходит, но возникает вопрос — каким должно быть возвращаемое значение? Как описать T + IInterface?

А нельзя возвращать общий базовый класс, который реализует оба инт-са?

S>А нельзя возвращать общий базовый класс, который реализует оба инт-са?

Хм... Тогда наследника:

T2 Resolve<TInterface> (this T1)
  where T2: T1
  where T2: TInterface
{
}

Окей, не уверен, но может сработать. В таком случае остается вопрос — как избавиться от необходимости вручную описывать типы?

Здравствуйте, LWhisper, Вы писали:


S>>А нельзя возвращать общий базовый класс, который реализует оба инт-са?

LW>Хм... Тогда наследника:
LW>

T2 Resolve<TInterface> (this T1)
LW>  where T2: T1
LW>  where T2: TInterface
LW>{
LW>}

LW>Окей, не уверен, но может сработать. В таком случае остается вопрос — как избавиться от необходимости вручную описывать типы?

Зачем тут (выше) вообще интерфейсы, всюду базовый класс, имл. ин-сы? А интерфейсы всплывают с в самом конце, как в исходном примере.