Dichiarazione di ereditarietà dell'interfaccia 'concatenata'

Question

Dichiarazione di ereditarietà dell'interfaccia 'concatenata'

#1 da (1 voti)
#2 da (1 voti)

1

I assume this is largely language-agnostic, but I'm working in C# if it's not

Diciamo che l'interfaccia I3 eredita da I2 , che a sua volta eredita da I1 . Potrei scrivere questo:

interface I1 { ... }
interface I2 : I1 { ... }
interface I3 : I2 { ... }

O in alternativa questo:

interface I1 { ... }
interface I2 : I1 { ... }
interface I3 : I1, I2 { ... }

Il I1 in interface I3 è ridondante - tutto ciò che implementa I3 richiederà comunque qualcosa dichiarato in I2 , che include qualsiasi cosa in I1 .

A mio parere, quest'ultimo è più leggibile - posso vedere a colpo d'occhio tutte le interfacce di "base" senza dover scavare giù l'albero di ereditarietà, ma non sono sicuro che sia considerato una buona pratica. È? Ci sono trappole nascoste qui?

interfaces inheritance

posta Kai 21.07.2015 - 13:59

fonte

2 risposte

1

Devi comunque scovare l'albero di ereditarietà - solo per scoprire il set di interfacce da cui ereditano tutte le interfacce ereditate e anche i loro figli. La differenza sta nel fatto che lo sviluppatore fa ciò quando sviluppano la classe invece di farlo quando hanno bisogno di sapere quali interfacce estendono la loro classe, se ne hanno bisogno.

Probabilmente è una buona cosa, rendendo esplicita l'elenco delle interfacce implementate da una classe.

risposta data 21.07.2015 - 14:13

fonte

Leggi altre domande sui tag interfaces inheritance

Un tutorial introduttivo per retropropagazione neurale con matematica semplificata GNU GPL quando applicato a Data

score 1 · Accepted Answer

Avere profonde gerarchie di interfacce è un po 'antipatico per me. Puzza di overengineering.

L'intero punto di avere interfacce è che consentono il riutilizzo del codice orizzontale anziché verticale (per ereditarietà).

Non conosco il contesto, forse non c'è modo di aggirarlo nel tuo caso. Forse è in qualche modo richiesto dalla struttura, dall'architettura o in altro modo dalla natura del tuo progetto - es. codice altamente astratto come le librerie standard.

Si noti che questo tipo di ridondanza può essere trovato in sorgenti .NET, ad esempio:

public interface IList : ICollection, IEnumerable

Anche se ICollection supporta già IEnumerable . Stessa cosa con le raccolte Java standard.

Qual è il costo di ciò? La ridondanza è ridondante, se un giorno decidi di rimuovere la dipendenza I2 ha su I1 , potresti doverlo fare in più punti o finire con una base di codice incoerente.

Il design non segue più il principio della "singola fonte di verità", poiché la dipendenza di I2 su I1 viene reiterata ovunque anziché dichiarata solo una volta.