Implementazione esplicita di membri di interfaccia
Un'interfaccia è un contratto per il supporto di determinate funzionalità. Le classi che implementano un'interfaccia devono fornire i dettagli di implementazione per i membri specificati in tale interfaccia. L'interfaccia IEnumerator, ad esempio, definisce le firme dei membri che è necessario implementare per il supporto dell'enumerazione su un insieme di oggetti. Per l'implementazione di IEnumerator, una classe deve implementare i membri Current, MoveNext e Reset.
Quando viene implementato esplicitamente da una classe, un membro di un'interfaccia risulta accessibile solo mediante un riferimento all'interfaccia. Questo comportamento ha l'effetto di nascondere il membro dell'interfaccia. In genere, un membro di un'interfaccia viene implementato esplicitamente non solo per garantire la conformità al contratto dell'interfaccia, ma anche per apportarvi miglioramenti, ad esempio per fornire metodi fortemente tipizzati da utilizzare in sostituzione dei metodi dell'interfaccia con tipizzazione debole. Un altro motivo per l'implementazione esplicita di un membro di un'interfaccia riguarda il caso in cui il membro non deve essere chiamato dagli sviluppatori. Il membro GetObjectData, ad esempio, è quasi sempre implementato in modo esplicito perché viene chiamato dall'infrastruttura di serializzazione e non deve essere normalmente chiamato dal codice.
Le linee guida di progettazione riportate di seguito contribuiscono a garantire che nel progetto di libreria le interfacce vengano implementate in modo esplicito solo quando opportuno.
Evitare di implementare esplicitamente membri di interfaccia senza un motivo fondato.
La comprensione del concetto di implementazione esplicita richiede un livello di competenza avanzato. Numerosi sviluppatori, ad esempio, non sanno che un membro implementato in modo esplicito è chiamabile pubblicamente, anche se la relativa firma è privata. Per questo motivo i membri implementati in modo esplicito non compaiono nell'elenco dei membri visibili pubblicamente. L'implementazione esplicita di un membro può inoltre causare il boxing non necessario dei tipi di valore.
Prendere in considerazione l'implementazione esplicita di membri di interfaccia se questi ultimi sono destinati a essere chiamati solo tramite l'interfaccia.
Tra questi sono inclusi i membri che supportano l'infrastruttura .NET Framework, ad esempio l'associazione dati o la serializzazione. La proprietà IsReadOnly, ad esempio, è destinata a essere accessibile solo all'infrastruttura di associazione dati tramite un riferimento all'interfaccia ICollection<T>. La classe List<T> implementa la proprietà in modo esplicito perché risulta conforme a questa linea guida.
Prendere in considerazione l'implementazione esplicita di membri di interfaccia per simulare la varianza, ossia cambiare i parametri o il tipo restituito nei membri sottoposti a override.
Questa operazione viene spesso effettuata per offrire versioni fortemente tipizzate dei membri di interfaccia.
Prendere in considerazione l'implementazione esplicita di membri di interfaccia per nascondere un membro e aggiungere un membro equivalente con un nome più appropriato.
In questo modo un membro viene effettivamente rinominato. Stream, ad esempio, implementa esplicitamente Dispose e fornisce in sostituzione il metodo Close.
Non utilizzare i membri espliciti come limite di sicurezza.
L'implementazione esplicita di un membro non garantisce alcuna sicurezza. Questi membri possono essere chiamati pubblicamente mediante un riferimento all'interfaccia.
Fornire un membro virtuale protetto in grado di offrire le stesse funzionalità del membro implementato in modo esplicito, nel caso in cui tali funzionalità siano destinate a essere specializzate da classi derivate.
Non è possibile eseguire l'override di membri implementati in modo esplicito. Se questi vengono ridefiniti in una classe derivata, per la classe derivata non sarà possibile chiamare l'implementazione della classe base. Si consiglia di assegnare al membro protetto lo stesso nome del membro di interfaccia esplicito oppure di aggiungere l'affisso Core a tale nome.
Portions Copyright 2005 Microsoft Corporation. Tutti i diritti riservati.
Portions Copyright Addison-Wesley Corporation. Tutti i diritti riservati.
Per ulteriori informazioni sulle linee guida di progettazione, vedere “le linee guida di progettazione di Framework: Idiomi convenzioni, e modelli per libro raccolte riutilizzabili .NET„ di Krzysztof Cwalina e brad Abrams, emessi da Addison-Wesley, 2005.
Vedere anche
Concetti
Altre risorse
Linee guida di progettazione dei membri
Linee guida di progettazione per lo sviluppo di librerie di classi