Зачем реализовать интерфейс явно?

Question

Итак, что именно хорошо подходит для реализации интерфейса явно?

Только ли людям, использующим класс, не нужно смотреть на все эти методы/свойства в intellisense?

Answer 1

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

public interface IDoItFast 
{ 
    void Go(); 
} 
public interface IDoItSlow 
{ 
    void Go(); 
} 
public class JustDoIt : IDoItFast, IDoItSlow 
{ 
    void IDoItFast.Go() 
    { 
    } 

    void IDoItSlow.Go() 
    { 
    } 
} 

Answer 2

Это также полезно, если у вас есть два интерфейса с одинаковым именем элемента и подписью, но хотите изменить поведение его зависимости, как она используется. (Я не рекомендую написание кода, как это):

interface Cat 
{ 
    string Name {get;} 
} 

interface Dog 
{ 
    string Name{get;} 
} 

public class Animal : Cat, Dog 
{ 
    string Cat.Name 
    { 
     get 
     { 
      return "Cat"; 
     } 
    } 

    string Dog.Name 
    { 
     get 
     { 
      return "Dog"; 
     } 
    } 
} 
static void Main(string[] args) 
{ 
    Animal animal = new Animal(); 
    Cat cat = animal; //Note the use of the same instance of Animal. All we are doing is picking which interface implementation we want to use. 
    Dog dog = animal; 
    Console.WriteLine(cat.Name); //Prints Cat 
    Console.WriteLine(dog.Name); //Prints Dog 
} 

Answer 3

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

Answer 4

Он может держать уборщик публичного интерфейса явно реализовать интерфейс, то есть ваш File класса может реализовать IDisposable явно и обеспечить публичный метод Close(), который мог бы сделать больше смысла для потребителя, чем Dispose().

F # только предлагает явную реализацию интерфейса, поэтому вам всегда нужно приложить к конкретному интерфейсу доступ к его функциям, что делает возможным использование явного (не предполагаемого) использования интерфейса.

Answer 5

Полезно скрыть нежелательный элемент. Например, если вы реализуете как IComparable<T>, так и IComparable, лучше всего скрыть перегрузку IComparable, чтобы не дать людям впечатление, что вы можете сравнивать объекты разных типов. Аналогично, некоторые интерфейсы не совместимы с CLS, например IConvertible, поэтому, если вы явно не реализуете интерфейс, конечные пользователи языков, которым требуется соответствие CLS, не могут использовать ваш объект. (Что было бы очень катастрофически, если бы исполнители BCL не скрывали IConvertible членов примитивов :))

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

void SomeMethod<T>(T obj) where T:IConvertible 

Не будет ящика в случае, если вы передадите его одному.

Answer 6

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

Например, объект может реализовать ICloneable, но все же его общедоступный метод Clone возвращает свой собственный тип.

Аналогичным образом, у IAutomobileFactory может быть метод изготовления, который возвращает автомобиль, но у FordExplorerFactory, который реализует IAutomobileFactory, может быть, что метод его изготовления возвращает FordExplorer (который происходит от Automobile). Код, который знает, что у него есть FordExplorerFactory, может использовать специальные свойства FordExplorer на объекте, возвращенном FordExplorerFactory, без необходимости приведения типов, тогда как код, который просто знал, что у него есть какой-то тип IAutomobileFactory, просто будет иметь дело с его возвратом в качестве Автомобиля.

Answer 7

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

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

чистый код: будет ошибкой компиляции, если метод Clone удаляется из ICloneable, однако, если вы реализуете метод неявно вы можете закончить с неиспользуемыми бесхозными публичными методами

Строгих типизацией : чтобы проиллюстрировать историю SUPERCAT с примером, это будет мой предпочтительный пример кода, внедрение ICloneable явно позволяет Clone() быть сильно типизированных при вызове его непосредственно в качестве члена в MyObject например:

public class MyObject : ICloneable 
{ 
    public MyObject Clone() 
    { 
    // my cloning logic; 
    } 

    object ICloneable.Clone() 
    { 
    return this.Clone(); 
    } 
} 

Answer 8

Другая причина для явной реализации - ремонтопригодность.

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

Таким образом, он улучшает «читаемость» кода.

Answer 9

Это, как мы можем создать Явный интерфейс: Если мы имеем 2 интерфейса и оба интерфейса имеют один и тот же метод и один класс наследует эти 2 интерфейсы, когда мы называем один метод интерфейса компилятор запутался, какой метод для вызова, поэтому мы можем справиться с этой проблемой с помощью Явного интерфейса. Вот один пример, который я привел ниже.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 

namespace oops3 
{ 
    interface I5 
    { 
     void getdata();  
    } 
    interface I6 
    { 
     void getdata();  
    } 

    class MyClass:I5,I6 
    { 
     void I5.getdata() 
     { 
      Console.WriteLine("I5 getdata called"); 
     } 
     void I6.getdata() 
     { 
      Console.WriteLine("I6 getdata called"); 
     } 
     static void Main(string[] args) 
     { 
      MyClass obj = new MyClass(); 
      ((I5)obj).getdata();      

      Console.ReadLine();  
     } 
    } 
} 

Answer 10

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

interface Iphone{ 

    void Money(); 

} 

interface Ipen{ 

    void Price(); 
} 


class Demo : Iphone, Ipen{ 

    void Iphone.Money(){ //it is private you can't give public    

     Console.WriteLine("You have no money"); 
    } 

    void Ipen.Price(){ //it is private you can't give public 

     Console.WriteLine("You have to paid 3$"); 
    } 

} 


// So you have to cast to call the method 


    class Program 
    { 
     static void Main(string[] args) 
     { 
      Demo d = new Demo(); 

      Iphone i1 = (Iphone)d; 

      i1.Money(); 

      ((Ipen)i1).Price(); 

      Console.ReadKey(); 
     } 
    } 

    // You can't call methods by direct class object 

Answer 11

Другой пример даются System.Collections.Immutable, в которых авторы решили использовать технику, чтобы сохранить привычный интерфейс для типов коллекций, а скребли части интерфейса, которые не несут никакого смысла для их новых типов ,

В частности, ImmutableList<T> реализует IList<T> и, таким образом, ICollection<T> (in order, чтобы позволить ImmutableList<T> использоваться более легко с унаследованным кодом), но void ICollection<T>.Add(T item) не имеет смысла в ImmutableList<T>: так как добавление элемента к неизменному списка не должны изменить существующий список , ImmutableList<T> также исходит из IImmutableList<T>, чьи IImmutableList<T> Add(T item) могут использоваться для целых списков.

Таким образом, в случае Add, реализации в ImmutableList<T> в конечном итоге выглядит следующим образом:

public ImmutableList<T> Add(T item) 
{ 
    // Create a new list with the added item 
} 

IImmutableList<T> IImmutableList<T>.Add(T value) => this.Add(value); 

void ICollection<T>.Add(T item) => throw new NotSupportedException(); 

int IList.Add(object value) => throw new NotSupportedException();