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

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

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

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

7 51
oop c# .net vb.net

7 ответов:

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

88

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

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

28

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

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# вы можете наследовать только от одного базового класса. Это означает, что это может быть не правильное решение для конкретной ситуации, но есть о чем подумать.

Тони.

9

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

8

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

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

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

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

6

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

0

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

Dim x as new IDoStuff()

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

0