Почему свойство реализации в VB.NET должно иметь соответствующие спецификаторы ReadOnly?

Question

Следующие работы в C #:

interface I
{
    int X { get; }
}

class C : I
{
    public int X
    {
        get { ... }
        set { ... }
    }
}

Следующее не работает в VB.NET:

Interface I
    ReadOnly Property X As Integer
End Interface

Class C
    Implements I

    Public Property X As Integer Implements I.X
        Get
            ...
        End Get
        Set(value As Integer)
            ...
        End Set
    End Property
End Class

Сообщение об ошибке Implementing property must have matching 'ReadOnly' or 'WriteOnly' specifiers говорит само за себя, поэтому я знаю, что здесь не так. Это тоже не большая проблема, потому что обойти это ограничение довольно просто.

Мне любопытно: кто-нибудь знает, почему дизайнеры VB решили рассматривать этот случай иначе, чем в C #?

Answer 1

Я не уверен насчет стороны VB, но с явной реализацией интерфейса I.X в C # вы также получите жалобу на добавленный сеттер:

interface I
{
    int X { get; }
}

class C : I
{
    int I.X  // explicit implementation of I.X
    {
        get { return 1; }
        set { }
    }
}

Вы получаете похожую ошибку в C #. Для VB может потребоваться проверить этот поток SO: Если интерфейс определяет свойство ReadOnly, как разработчик может предоставить Setter этому свойству?

Answer 2

Для реализации IX необходимо предоставить свойство только для чтения;если вы хотите, чтобы YourClass.X был свойством чтения-записи, то только для чтения, который реализует IX, должно быть дано другое имя (например,

    Public Property Xreadonly As Integer Implements I.X

. Я не совсем уверен, почему .Net требует использованиятрех типов свойств (только для чтения, только для записи и чтения-записи), вместо того, чтобы просто использовать объект, который объявляет свойство только для чтения и свойство только для записи, как если бы он имел чтение-записьсвойство, но это так. Возможно, это потому, что они хотели убедиться, что переопределение получателя будет следовать тому же пути наследования, что и переопределение установщика, но может показаться, что в некоторых случаях использование получателей и установщиков в качестве отдельных элементов будет болееполезно (в некоторых случаях, например, может быть полезно, чтобы свойство Get возвращало тип, отличный от типа метода Set, но принудительно применяемый к нему; или может быть полезно иметь несколько перегрузок Set;разрешено в .net, хотя).

Answer 3

У вас есть ReadOnly для свойства в Interface I, но не в унаследованном Class C, поэтому подписи свойства не совпадают, следовательно, ошибка.Я уверен, что вы не можете добавить set средство доступа к ReadOnly свойству тоже.