Не публичные пользователи для интерфейсов C #

В C #, когда вы реализуете интерфейс, все члены неявно публично. Было бы лучше, если бы мы могли указать модификатор доступности ( protected , internal , за исключением private конечно), или же мы просто должны использовать абстрактный class?

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

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

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

Для защищенных членов, которые вызывается базовым classом, абстрактные classы – это путь для определения контракта между базовыми classами и classами, которые наследуются от них. Но в этом случае детали реализации, как правило, очень важны, если только это не вырожденный чистый абстрактный class (где все члены абстрактны), и в этом случае защищенные члены бесполезны. В этом случае перейдите к интерфейсу и сохраните единственный базовый class для выбора типов.

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

 public interface IInterface { public void Method(); } public class A : IInterface { public void IInterface.Method() { // Do something } } public class Program { public static void Main() { A o = new A(); o.Method(); // Will not compile ((IInterface)o).Method(); // Will compile } } 

Не имеет смысла. Интерфейс – это контракт с общественностью о том, что вы поддерживаете эти методы и свойства. Придерживайтесь абстрактных classов.

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

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

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

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

Возникает вопрос, почему не были интерфейсы, предназначенные для определения непубличных определений для членов. Это может сделать договор гибким. Это очень полезно при написании сборок, где вы не хотите, чтобы определенные члены classов подвергались воздействию вне сборки. Я не знаю почему.

Интерфейс – это контракт, которым придерживаются все реализующие classы. Это означает, что они должны придерживаться всего этого или ничто из этого.

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

Либо используйте абстрактный базовый class или (если возможно, и практический) внутренний метод расширения на интерфейсе .

Вы можете скрыть почти весь код, реализованный интерфейсами, с внешними assemblyми.

 interface IVehicle { void Drive(); void Steer(); void UseHook(); } abstract class Vehicle // :IVehicle // Try it and see! { ///  /// Consuming classes are not required to implement this method. ///  protected virtual void Hook() { return; } } class Car : Vehicle, IVehicle { protected override void Hook() // you must use keyword "override" { Console.WriteLine(" Car.Hook(): Uses abstracted method."); } #region IVehicle Members public void Drive() { Console.WriteLine(" Car.Drive(): Uses a tires and a motor."); } public void Steer() { Console.WriteLine(" Car.Steer(): Uses a steering wheel."); } ///  /// This code is duplicated in implementing classes. Hmm. ///  void IVehicle.UseHook() { this.Hook(); } #endregion } class Airplane : Vehicle, IVehicle { protected override void Hook() // you must use keyword "override" { Console.WriteLine(" Airplane.Hook(): Uses abstracted method."); } #region IVehicle Members public void Drive() { Console.WriteLine(" Airplane.Drive(): Uses wings and a motor."); } public void Steer() { Console.WriteLine(" Airplane.Steer(): Uses a control stick."); } ///  /// This code is duplicated in implementing classes. Hmm. ///  void IVehicle.UseHook() { this.Hook(); } #endregion } 

Это проверит код.

 class Program { static void Main(string[] args) { Car car = new Car(); IVehicle contract = (IVehicle)car; UseContract(contract); // This line is identical... Airplane airplane = new Airplane(); contract = (IVehicle)airplane; UseContract(contract); // ...to the line above! } private static void UseContract(IVehicle contract) { // Try typing these 3 lines yourself, watch IDE behavior. contract.Drive(); contract.Steer(); contract.UseHook(); Console.WriteLine("Press any key to continue..."); Console.ReadLine(); } } 

Интерфейсы не имеют модификаторов доступа в своих методах, оставляя их открытыми в зависимости от того, какой модификатор доступа подходит. Это имеет целью: позволяет другим типам определять, какие методы и свойства доступны для объекта, следующего за интерфейсом. Предоставление им защищенных / внутренних аксессуаров поражает цель интерфейса.

Если вы категоричны, что вам необходимо предоставить модификатор доступа для метода, либо оставьте его вне интерфейса, либо, как вы сказали, используйте абстрактный class.

Я знаком с Java, а не с C #, но почему земля вы хотите получить частный член в интерфейсе? Это не могло быть реализовано и было бы невидимым для реализации classов, поэтому было бы бесполезно. Существуют интерфейсы для указания поведения. Если вам требуется поведение по умолчанию, чем использование абстрактного classа.

В моей операции это нарушает инкапсуляцию. Я должен реализовать methos как public, тогда я реализую интерфейс. Я не вижу причин принуждать публику к classу, который реализует интерфейс. (C #)

  • Почему все поля в интерфейсе неявно статичны и окончательны?
  • Почему я не могу понять интерфейсы?
  • Почему мы используем интерфейс? Это только для стандартизации?
  • Как выполнить бинарный поиск в IList ?
  • Разница между интерфейсами Runnable и Callable в Java
  • Внедрение интерфейса TypeScript с сигнатурой голосовой функции и другими полями
  • Создание интерфейса FORTRAN для функции C, которая возвращает символ char *
  • В чем разница между интерфейсом и абстрактным classом?
  • интерфейс как параметр метода в Java
  • Отражение Java: создание classа реализации
  • Что такое интерфейс в Java?
  • Interesting Posts

    Уведомление Push неправильно работает, когда приложение находится в фоновом режиме или не работает

    Неполадка контекста ошибки сборки IntelliJ

    Photoshop CS4, мой инструмент линии теперь рисует стрелки, как мне вернуть значение по умолчанию и что это такое?

    Печать значка jLabel в принтере с помощью кнопки

    Как получить обратную шкалу log10 в ggplot2?

    Нарисуйте 3D-векторы

    Как проверить, является ли бинарный файл 32 или 64 бит в Windows?

    Oracle Искать все таблицы для всех столбцов для строки

    Простой инструмент для захвата изображений для Mac OS X, который использует FireWire

    static vs extern “C” / “C ++”

    Java, Как реализовать Shift Cipher (Цезарский шифр)

    Получить все веб-элементы управления определенного типа на странице

    Преобразование равномерного распределения в нормальное распределение

    Как подсчитать уникальные символы в строке

    Поиск библиотеки проверки орфографии Java

    Давайте будем гением компьютера.