È consentito utilizzare l'implementazione esplicita dell'interfaccia per nascondere i membri in C #?

Capisco come lavorare con le interfacce e l'implementazione esplicita dell'interfaccia in C #, ma mi chiedevo se fosse considerata una cattiva forma per nascondere alcuni membri che non sarebbero stati usati frequentemente. Per esempio:

public interface IMyInterface
{
    int SomeValue { get; set; }
    int AnotherValue { get; set; }
    bool SomeFlag { get; set; }

    event EventHandler SomeValueChanged;
    event EventHandler AnotherValueChanged;
    event EventHandler SomeFlagChanged;
}

So in anticipo che gli eventi, sebbene utili, verrebbero usati molto raramente. Pertanto, ho pensato che avrebbe senso nasconderli lontano da una classe di implementazione tramite un'implementazione esplicita per evitare il disordine di IntelliSense.

Sì, è generalmente in cattiva forma.

Pertanto, ho pensato che avrebbe senso nasconderli lontano da una classe di implementazione tramite un'implementazione esplicita per evitare il disordine di IntelliSense.

Se IntelliSense è troppo disordinato, la tua classe è troppo grande. Se la tua classe è troppo grande, probabilmente sta facendo troppe cose e / o mal progettato.

Risolvi il tuo problema, non il sintomo.

Usa la funzione per quello a cui era destinata. Ridurre il disordine dello spazio dei nomi non è uno di quelli.

Le ragioni legittime non riguardano il "nascondersi" o l'organizzazione, ma per risolvere l'ambiguità e specializzarsi. Se si implementano due interfacce che definiscono "Foo", la semantica di Foo potrebbe essere diversa. Davvero non è un modo migliore per risolvere questo, tranne per le interfacce esplicite. L'alternativa è impedire l'implementazione di interfacce sovrapposte o dichiarare che le interfacce non possono associare la semantica (che comunque è solo una cosa concettuale). Entrambe sono alternative scadenti. A volte la praticità supera l'eleganza.

Alcuni autori / esperti lo considerano un kludge di una caratteristica (i metodi non fanno realmente parte del modello a oggetti del tipo). Ma come tutte le funzionalità, da qualche parte, qualcuno ne ha bisogno.

Ancora una volta, non lo userei per nascondermi o organizzazione. Ci sono modi per nascondere i membri dall'intellisense.

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Potrei essere un segno di codice disordinato, ma a volte il mondo reale è disordinato. Un esempio di .NET framework è ReadOnlyColection che nasconde il setter mutante [], Aggiungi e Imposta.

IE ReadOnlyCollection implementa IList <T>. Vedi anche la mia domanda a SO diversi anni fa, quando ho riflettuto su questo.

È una buona forma farlo quando il membro è inutile nel contesto. Ad esempio, se crei una raccolta di sola lettura che implementa IList<T>delegando a un oggetto interno _wrapped, potresti avere qualcosa del tipo:

public T this[int index]
{
  get
  {
     return _wrapped[index];
  }
}
T IList<T>.this[int index]
{
  get
  {
    return this[index];
  }
  set
  {
    throw new NotSupportedException("Collection is read-only.");
  }
}
public int Count
{
  get { return _wrapped.Count; }
}
bool ICollection<T>.IsReadOnly
{
  get
  {
    return true;
  }
}

Qui abbiamo quattro casi diversi.

public T this[int index]è definito dalla nostra classe piuttosto che dall'interfaccia, e quindi ovviamente non è un'implementazione esplicita, sebbene si noti che sembra essere simile alla lettura-scrittura T this[int index]definita nell'interfaccia ma è di sola lettura.

T IList<T>.this[int index]è esplicito perché una parte di esso (il getter) è perfettamente abbinata dalla proprietà sopra e l'altra parte genererà sempre un'eccezione. Mentre è vitale per qualcuno accedere a un'istanza di questa classe tramite l'interfaccia, è inutile che qualcuno la usi attraverso una variabile del tipo di classe.

Allo stesso modo perché bool ICollection<T>.IsReadOnly tornerà sempre vero, è assolutamente inutile il codice scritto contro il tipo di classe, ma potrebbe essere vitale per usarlo attraverso il tipo di interfaccia, e quindi lo implementiamo esplicitamente.

Al contrario, public int Countnon viene implementato esplicitamente perché potrebbe essere potenzialmente utile a qualcuno che utilizza un'istanza attraverso il proprio tipo.

Ma con il tuo caso "usato molto raramente", mi spingerei molto fortemente a non usare un'implementazione esplicita.

Nei casi in cui consiglio di utilizzare un'implementazione esplicita che chiama il metodo tramite una variabile del tipo di classe, si tratterebbe di un errore (tentativo di utilizzare il setter indicizzato) o inutile (controllo di un valore che sarà sempre lo stesso), quindi nascondersi li stai proteggendo l'utente da buggy o codice non ottimale. È significativamente diverso dal codice che ritieni possa essere usato raramente . Per questo potrei considerare di usare l' EditorBrowsableattributo per nascondere il membro dall'intellisense, anche se anche se ne sarei stanco; il cervello delle persone ha già il proprio software per filtrare ciò che non li interessa.