Как вы можете требовать конструктор без параметров для типов, реализующих интерфейс?

чтобы не быть слишком грубым, но вы неправильно поняли цель интерфейсы.

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

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

Хуан

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

(ed: удалено ошибочное альтернативное решение)

причина в том, что, к сожалению, невозможно использовать интерфейсы, абстрактные классы или виртуальные методы в сочетании с конструкторами или статическими методами. Краткость причина в том, что первые не содержат явной информации о типе, а последние требуют явной информации о типе.

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

вся точка интерфейса, абстрактного класса или виртуального метода должна быть в состоянии сделать вызов функции без явная информация о типе, и это включено тем фактом, что есть экземпляр, на который ссылаются, который имеет "скрытую" информацию о типе, не доступную непосредственно вызывающему коду. Таким образом, эти два механизма являются взаимоисключающими. Они не могут использоваться вместе, потому что, когда вы их смешиваете, у вас нет конкретного типа информация вообще в любом месте, что означает, что среда выполнения не знает, где найти функцию, которую вы просите ее вызвать.

можно использовать ограничение параметра типа

interface ITest<T> where T: new()
{
    //...
}

class Test: ITest<Test>
{
    //...
}

нужно вещь который может создавать экземпляры неизвестного типа, реализующие интерфейс. У вас есть в основном три варианта: объект фабрики, объект типа или делегат. Вот данные:

public interface IInterface
{
    void DoSomething();
}

public class Foo : IInterface
{
    public void DoSomething() { /* whatever */ }
}

использование типа довольно уродливо, но имеет смысл в некоторых сценариях:

public IInterface CreateUsingType(Type thingThatCreates)
{
    ConstructorInfo constructor = thingThatCreates.GetConstructor(Type.EmptyTypes);
    return (IInterface)constructor.Invoke(new object[0]);
}

public void Test()
{
    IInterface thing = CreateUsingType(typeof(Foo));
}

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

самым распространенным решением является использование фабрики:

public interface IFactory
{
    IInterface Create();
}

public class Factory<T> where T : IInterface, new()
{
    public IInterface Create() { return new T(); }
}

public IInterface CreateUsingFactory(IFactory factory)
{
    return factory.Create();
}

public void Test()
{
    IInterface thing = CreateUsingFactory(new Factory<Foo>());
}

в вышеуказанном, IFactory что действительно имеет значение. Factory - это просто класс удобства для классов, которые do предоставить конструктор по умолчанию. Это самое простое и часто лучшее решение.

третье в настоящее время необычное, но, вероятно, более распространенное решение использует делегат:

public IInterface CreateUsingDelegate(Func<IInterface> createCallback)
{
    return createCallback();
}

public void Test()
{
    IInterface thing = CreateUsingDelegate(() => new Foo());
}

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

вызовите метод RegisterType с типом и ограничьте его с помощью дженериков. Затем вместо ходячих сборок для поиска реализаторов ITest просто сохраните их и создайте оттуда.

void RegisterType<T>() where T:ITest, new() {
}

Я так не думаю.

вы также не можете использовать абстрактный класс для этого.

Я хотел бы напомнить всем, что:

1. написание атрибутов в .NET легко
2. написание инструментов статического анализа в .NET, которые обеспечивают соответствие стандартам компании легко

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

язык, компилятор, IDE, ваш мозг-все это инструменты. Используй их!

нет, вы не можете сделать это. Может быть, для вашей ситуации был бы полезен заводской интерфейс? Что-то вроде:

interface FooFactory {
    Foo createInstance();
}

для каждой реализации Foo вы создаете экземпляр FooFactory, который знает, как его создать.

вам не нужен конструктор без параметров для активатора для создания экземпляра вашего класса. Вы можете иметь параметризованный конструктор и передавать все параметры из активатора. Проверьте MSDN на этом.