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


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

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

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

7   51  

7 ответов:

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

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

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

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

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

Тони.

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

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

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

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

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

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

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

Dim x as new IDoStuff()

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