Использование статических, внутренних и защищенных модификаторов доступа в интерфейсах c # 8 - PullRequest
Новая
       15

Использование статических, внутренних и защищенных модификаторов доступа в интерфейсах c # 8

3 голосов
/ 06 ноября 2019

C # 8 теперь поддерживает модификаторы доступа для членов интерфейса, и его использование смущает меня. Возьмите следующий пример 

public interface IFoobar 
{   // these members are all valid
    protected string Protected { get; set; }
    internal string Internal { get; set; }
    static string Static { get; set; }
}

public class Foobar : IFoobar // <-- error, Internal and Protected members not implemented
{
    protected string Protected { get; set; }
    internal string Internal { get; set; }
    static string Static { get; set; } // only this one implements IFoobar
}

Я ожидал, что Foobar выше будет полностью реализовывать IFoobar. Однако это относится только к Static, другие - нет.

Может ли кто-то

  • объяснить, почему он ведет себя иначе (и отличается от pre-c # 8)? члены интерфейса)
  • дайте мне пример использования каждого из трех модификаторов в интерфейсе, подобном этому?

Спасибо

[править]

Мне известно, что при использовании явной реализации интерфейса будут реализованы члены, но для членов интерфейса до c # 8 это был не единственный выход. Почему это отличается от новых членов?

1 Ответ

5 голосов
/ 06 ноября 2019

Я знаю, что при использовании явной реализации интерфейса будут реализованы члены, но для членов интерфейса до c # 8 это был не единственный выход. Почему это отличается от новых участников?

Похоже, что это дизайн . Вот соответствующий текст:

Неявно реализующие непубличные элементы интерфейса

Разрешили бы мы неявно реализовывать непубличные члены интерфейса? Если да, что требуется от доступности метода реализации? Некоторые опции:

  • Должен быть общедоступным
  • Должен быть точно такой же доступ
  • Должен быть как минимум максимально доступным

Заключение

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

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

А почему так, то это вопрос для дизайнеров. Формулировка из LDM не делает его звучащим так, как будто он установлен в камне. Так что возможно неявно реализованные члены с измененным доступом будут разрешены в будущем.

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

public interface IFoobar
{   // these members are all valid
    protected string Protected { get; set; }
    internal string Internal { get; set; }
    static string Static { get; set; }
}

public class Foobar : IFoobar
{
    string IFoobar.Protected {get;set;}
    string IFoobar.Internal {get;set;}
}
...