Se un'interfaccia eredita un'altra interfaccia

Question

Non riesco a trovare una risposta su questo e voglio solo essere sicuro che sia uno standard di codifica ok. Ho un'interfaccia A che viene utilizzata da molte classi diverse e non voglio che l'interfaccia A cambi. Mi sono imbattuto in un nuovo requisito che richiederà l'enumerazione di molte delle classi che implementano l'interfaccia A, ma non tutte le classi hanno bisogno di questo enum. Non voglio le classi che non richiedono questo nuovo enum per implementare questa nuova funzionalità. Così ho creato l'interfaccia B che contiene il nuovo enum che dovevo aggiungere. Ho quindi realizzato un'interfaccia E1 di interfaccia B di A e questa è la mia preoccupazione, è ok per un'interfaccia per ereditare un'altra interfaccia? Per continuare con le mie modifiche, ho quindi modificato le classi che avevano bisogno del nuovo enum per implementare l'interfaccia B invece dell'interfaccia A poiché era ereditata dall'interfaccia B. Ho pensato di implementare entrambe le interfacce nelle mie classi che ne avevano bisogno, ma sto usando il Interfaccia su tutto il codice e vorrebbe usare solo un'interfaccia per guardare attraverso le classi e non due.

Spero che questo sia stato abbastanza chiaro (probabilmente troppo lungo) ma se qualcuno può darmi qualche consiglio su questo o sto facendo bene o sto sbagliando per favore fammi sapere.

Grazie!

Answer 1

L'ereditarietà dell'interfaccia è uno strumento eccellente, anche se dovresti usarlo solo quando l'interfaccia B è veramente sostituibile all'interfaccia A, non solo per aggregare comportamenti vagamente correlati.

È difficile dire se è appropriato per il caso specifico, ma non c'è nulla di sbagliato nella pratica in linea di principio. Lo vedi sempre nelle API di prim'ordine. Per scegliere solo un esempio comune, dal .NET framework:

public interface ICollection<T> : IEnumerable<T>, IEnumerable 

Answer 2

IMO questo è esattamente l'approccio giusto, non vedo alcun problema con esso.

Answer 3

È certamente possibile avere un albero di ereditarietà di interfacce e persino "eredità multipla" con interfacce. Se sia la cosa giusta da fare o meno dipende dalle interfacce in questione. Se è davvero il caso che l'interfaccia B sia un'estensione o un perfezionamento dell'interfaccia A, allora l'ereditarietà ha senso, ma se la nuova enumerazione è largamente scollegata dal concetto espresso dall'interfaccia A, vorrei renderli due interfacce separate e avere le classi che devono implementare entrambe le interfacce.

Answer 4

Tecnicamente parlando, le interfacce non ereditano l'una dall'altra. Ciò che accade realmente quando si crea un eredita da , si dice che qualsiasi classe che implementa IFoo deve implementare anche IBar.

interface IBar 
{ 
    void DoBar(); 
} 

interface IFoo : IBar 
{ 
    void DoFoo(); 
} 

In questo esempio, l'interfaccia IFoo non ha un metodo DoBar(). La maggior parte delle volte la distinzione non ha importanza, ma può morderti quando usi la riflessione su un'interfaccia piuttosto che su una classe.

Answer 5

Penso database forniscono sempre un ottimo modo per dimostrare le interfacce, in modo da prendere in considerazione se l'interfaccia dovrebbe ereditare un altro sguardo interfaccia al seguente,

IMySqlDatabase : IDatabase 
MySqlDatabase : IMySqlDatabase 

IMsSqlDatabase : IDatabase 
MsSqlDatabase : IMsSqlDatabase 

Un MySqlDatabase è un IMySqlDatabase e un IMySqlDatabase è un IDatabase.

Ora, se è necessario apportare modifiche all'interfaccia IDatabase, i nipoti (le classi di database conrete) possono trarre vantaggio, ma non sarà necessario espandere MySQL AND MsSQL (o forse anche più interfacce DBMS).Allo stesso tempo nel tuo intermediario (IMsSqlDatabase) puoi ancora avere caratteristiche di interfaccia che un DB MySQL o Oracle non supporterebbe.

Answer 6

Considerare se le interfacce devono essere accoppiate in modo logico e se si ritiene che funzionino bene tra loro, quindi utilizzare assolutamente l'ereditarietà.

Consente di guardare un esempio;

public interface IScanner 
{ 
    void Scan(); 
} 

public interface IPrinter 
{ 
    void Print(); 
} 

stampanti e scanner sono spesso oggetti separati, ciascuno con la propria funzionalità tuttavia questi due dispositivi sono spesso accoppiati nello stesso dispositivo;

public interface IPhotocopier : IScanner, IPrinter 
{ 
    void Copy(); 
} 

ha senso che IPhotocopier dovrebbe ereditare da iScanner e IPrinter quanto ciò permette ora la fotocopiatrice da utilizzare come uno scanner o una stampante (che contiene) in aggiunta alla sua cilindro principale come copiatrice.

Ora consente di guardare un'altra interfaccia;

public interface IBlender 
{ 
    void Blend(); 
} 

Non avrebbe senso per consentire IBlender a essere ereditata da una delle interfacce precedenti (cosa vorresti chiamarli? IBlendingScanner?).

Se non è possibile dare un nome ragionevole alla nuova interfaccia, è possibile che in questa istanza non si desideri utilizzare l'ereditarietà.

È una cattiva idea ereditare alcune interfacce come IDisposable, poiché ciò impone a tutte le implementazioni della nuova interfaccia di implementare lo schema di smaltimento anche se non dispongono di risorse disponibili.