Scelta tra classi e interfacce
Un'interfaccia definisce le firme per un insieme di membri che deve essere fornito dai responsabili dell'implementazione. Le interfacce non possono fornire dettagli di implementazione per i membri. L'interfaccia ICollection, ad esempio, definisce i membri che vengono utilizzati nella gestione degli insiemi. Ciascuna classe che implementa l'interfaccia deve fornire i dettagli di implementazione per questi membri. Le classi possono implementare più interfacce.
Le classi definiscono sia le firme dei membri che i dettagli di implementazione per ciascun membro. Le classi Abstract (MustInherit in Visual Basic) possono comportarsi come delle normali classi o interfacce in quanto possono definire membri e possono eventualmente fornire dettagli di implementazione. Se una classe astratta non fornisce dettagli di implementazione, per fornire l'implementazione sono necessarie classi concrete che ereditano dalla classe astratta.
Mentre entrambe le classi astratte e le interfacce supportano la separazione del contratto dall'implementazione, nelle versioni successive le interfacce non possono specificare nuovi membri, mentre le classi astratte possono aggiungere membri per supportare funzionalità aggiuntive.
Preferire la definizione di classi anziché di interfacce.
Nelle versioni successive della libreria, è possibile aggiungere nuovi membri alle classi in maniera sicura, mentre l'aggiunta di membri alle interfacce implica sempre l'interruzione di codice esistente.
Utilizzare classi astratte (MustInherit in Visual Basic) anziché interfacce per separare il contratto dalle implementazioni.
Se occorre fornire una gerarchia polimorfica di tipi di valore, definire un'interfaccia.
I tipi di valore devono ereditare da ValueType e possono ereditare solo da ValueType. Non possono quindi utilizzare delle classi per separare il contratto dall'implementazione. In tal caso, se i tipi di valore richiedono un comportamento polimorfico è necessario utilizzare un'interfaccia.
Per ottenere un effetto simile a quello di un'ereditarietà multipla, si consiglia di definire delle interfacce.
Se un tipo deve implementare più contratti o il contratto può essere applicato a un'ampia gamma di tipi, utilizzare un'interfaccia. L'interfaccia IDisposable, ad esempio, viene implementata da tipi utilizzati in numerosi scenari diversi. Se si impostano le classi perché ereditino da una classe base, la gerarchia di classi risulta poco flessibile. Le classi quali MemoryStream, che devono ereditare i contratti basati sul flusso dalle relative classi padre, non sarebbero in grado di ereditare da tali classi e sarebbero quindi eliminabili.
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 tipi
Linee guida di progettazione per lo sviluppo di librerie di classi