Perché implementare l'interfaccia in modo esplicito?

Question

Quindi, qual è esattamente un buon caso d'uso per implementare un'interfaccia esplicitamente?

E 'solo in modo che le persone che utilizzano la classe non devono guardare a tutti quei metodi/proprietà a intellisense?

Answer 1

Se si implementano due interfacce, entrambe con lo stesso metodo e diverse implementazioni, è necessario implementarle in modo esplicito.

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

    void IDoItSlow.Go() 
    { 
    } 
} 

Answer 2

E 'utile anche quando si dispone di due interfacce con lo stesso nome utente e la firma, ma vuole cambiare il comportamento di esso a seconda di come viene utilizzato. (Non consiglio scrittura di codice come questo):

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

Se si dispone di un'interfaccia interna e non si desidera implementare i membri sulla tua classe pubblicamente, li si implementa in modo esplicito. Le implementazioni implicite devono essere pubbliche.

Answer 4

può mantenere il pulitore interfaccia pubblica di implementare in modo esplicito un'interfaccia, vale a dire la classe File potrebbe implementare IDisposable esplicitamente e fornire un metodo pubblico Close() che potrebbe rendere più senso per un consumatore rispetto Dispose().

F # solo offre un'implementazione esplicita dell'interfaccia, quindi è sempre necessario eseguire il cast sull'interfaccia specifica per accedere alla sua funzionalità, il che rende molto esplicito (nessun gioco di parole) l'uso dell'interfaccia.

Answer 5

È utile nascondere il membro non preferito. Ad esempio, se si implementano sia IComparable<T> e IComparable, in genere è meglio nascondere l'overload IComparable per non dare alle persone l'impressione di poter confrontare oggetti di tipi diversi. Allo stesso modo, alcune interfacce non sono compatibili con CLS, come IConvertible, quindi se non si implementa esplicitamente l'interfaccia, gli utenti finali di lingue che richiedono la conformità CLS non possono utilizzare l'oggetto. (Che sarebbe molto disastroso se gli implementatori di BCL non nascondessero i membri IConvertible dei primitivi :))

Un'altra nota interessante è che normalmente usando un tale costrutto significa che la struct che implementa esplicitamente un'interfaccia può solo invocarli per boxe al tipo di interfaccia. Si può ovviare a questo utilizzando i vincoli generici ::

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

non sarà casella un int quando si passa uno ad esso.

Answer 6

Un'altra tecnica utile è di avere attuazione pubblico di una funzione di un metodo restituire un valore che è più preciso quanto specificato in un'interfaccia.

Ad esempio, un oggetto può implementare ICloneable, ma hanno ancora il suo metodo Clone pubblicamente visibile ritorno proprio tipo.

Allo stesso modo, un IAutomobileFactory potrebbe avere un metodo di fabbricazione che restituisce un automobile, ma un FordExplorerFactory, che implementa IAutomobileFactory, potrebbe avere il suo metodo Produzione restituire un Ford Explorer (che deriva da Automobile). Il codice che sa di avere un FordExplorerFactory potrebbe utilizzare le proprietà specifiche di FordExplorer su un oggetto restituito da un FordExplorerFactory senza dover digitare, mentre il codice che semplicemente sapeva che aveva un tipo di IAutomobileFactory avrebbe semplicemente gestito il suo ritorno come Automobile.

Answer 7

Alcuni motivi ulteriori per implementare un'interfaccia in modo esplicito:

retrocompatibilità: Nel caso in cui le ICloneable cambiamenti di interfaccia, di attuazione i membri della classe di metodo non devono cambiare le loro firme del metodo.

codice più pulito: ci sarà un errore del compilatore se il metodo Clone viene rimosso dal ICloneable, se si implementa il metodo implicitamente si può finire con metodi pubblici 'orfani' inutilizzati

tipizzazione forte : per illustrare la storia di supercat con un esempio, questo sarebbe il mio codice di esempio preferito, l'implementazione ICloneable permette esplicitamente Clone() da fortemente tipizzato quando si chiama direttamente come membro MyObject esempio:

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

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

Answer 8

Un altro motivo per l'implementazione esplicita è per la manutenzione .

Quando una classe diventa "occupata" - sì, succede, non abbiamo tutti il ​​lusso di refactoring del codice di altri membri del team - quindi avere un'implementazione esplicita rende chiaro che un metodo è lì per soddisfare un contratto di interfaccia.

Così migliora la "leggibilità" del codice.

Answer 9

Questo è come possiamo creare interfacce esplicite: Se abbiamo 2 interfaccia e sia l'interfaccia di avere lo stesso metodo e una sola classe erediterà questi 2 interfacce in modo che quando si chiama un metodo di interfaccia al compilatore un po 'confusa quale metodo per essere chiamato, così possiamo gestire questo problema usando l'interfaccia esplicita. Ecco un esempio che ho fornito di seguito.

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

In caso di interfacce esplicitamente definite, tutti i metodi sono automaticamente privati, non è possibile fornire ad essi un modificatore di accesso. Supponiamo:

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

Un esempio diverso è dato da System.Collections.Immutable, in cui gli autori hanno scelto di utilizzare la tecnica di conservare un API familiare per i tipi di raccolta, mentre raschiando via le parti dell'interfaccia che portano alcun significato per loro nuovi tipi .

Concretamente, ImmutableList<T> implementa IList<T> e quindi ICollection<T> (in order per consentire ImmutableList<T> da utilizzare più facilmente con il codice legacy), eppure void ICollection<T>.Add(T item) non ha alcun senso per un ImmutableList<T>: dal momento che l'aggiunta di un elemento a un elenco immutabile, non deve modificare l'elenco esistente , ImmutableList<T> deriva anche da IImmutableList<T> di cui IImmutableList<T> Add(T item) può essere utilizzato per elenchi immutabili.

Pertanto, nel caso di Add, le implementazioni in ImmutableList<T> finire in cerca come segue:

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();