Почему нам не разрешено указывать конструктор в интерфейсе?

Question

Возможный дубликат:
Интерфейс, определяющий сигнатуру конструктора?

Я знаю, что вы не можете указать конструктор в интерфейсе.Net, но почему мы не можем?

Для моего текущего проекта было бы очень полезно иметь возможность указать, что "конструктор" должен быть передан конструктору, но, как я не могу, мне достаточно XML-комментария к классу.

Answer 1

Потому что интерфейс описывает поведение. Конструкторы - это не поведение. Как строится объект - это деталь реализации.

Answer 2

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

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

Answer 3

Нет, вы не можете иметь конструкторы на интерфейсах по причинам, которые были опубликованы. Однако вы можете на абстрактных классах. Допустим, например, у вас есть этот базовый класс.

public abstract class ClassOne
{
    protected int _x;
    protected string _s;

    public ClassOne(int x, string s)
    {
        _x = x;
        _s = s;
    }        
}

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

Так что это недействительно и не будет компилироваться.

public class ClassTwo : ClassOne
{
    public ClassTwo() 
    { }
}

Однако это действительно и будет компилироваться.

public class ClassTwo : ClassOne
{
    public ClassTwo(int x, string s) : base(x, s)
    {  }
}

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

Тони.

Answer 4

Среди всех других уже упомянутых причин имейте в виду, что класс может легко реализовать несколько интерфейсов; какой конструктор следует использовать тогда?

Answer 5

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

Чтобы привести пример, основанный на вашем вопросе: вы говорите, что хотели бы как-то объявить, что "движок" должен быть передан конструктору. Вы можете сделать это, объявив отдельный интерфейс для службы конструирования, например так:

public interface IGadgetFactory
{
   IGadget CreateGadget(Engine engine);
}

Любой код, который должен создать IGadget экземпляры могут затем использовать IGadgetFactory экземпляр вместо вызова любых конструкторов напрямую.

Answer 6

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

Answer 7

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

Dim x as new IDoStuff()

Какая реализация вызывается?