Un'interfaccia è considerata "vuota" se eredita da altre interfacce?

Le interfacce vuote sono generalmente considerate cattive pratiche, per quanto ne so, specialmente dove cose come gli attributi sono supportate dal linguaggio.

Tuttavia, un'interfaccia è considerata "vuota" se eredita da altre interfacce?

interface I1 { ... }
interface I2 { ... } //unrelated to I1

interface I3
    : I1, I2
{
    // empty body
}

Qualunque cosa che gli attrezzi I3debbano implementare I1e I2, e gli oggetti di diverse classi che ereditano I3possono quindi essere usati in modo intercambiabile (vedi sotto), quindi è giusto chiamare I3 vuoto ? In caso affermativo quale sarebbe un modo migliore per l'architettura questo?

// with I3 interface
class A : I3 { ... }
class B : I3 { ... }

class Test {
    void foo() {
        I3 something = new A();
        something = new B();
        something.SomeI1Function();
        something.SomeI2Function();
    }
}

// without I3 interface
class A : I1, I2 { ... }
class B : I1, I2 { ... }

class Test {
    void foo() {
        I1 something = new A();
        something = new B();
        something.SomeI1Function();
        something.SomeI2Function(); // we can't do this without casting first
    }
}

Tutto ciò che implementa I3 dovrà implementare I1 e I2, e gli oggetti di diverse classi che ereditano I3 possono quindi essere usati in modo intercambiabile (vedi sotto), quindi è giusto chiamare I3 vuoto? In caso affermativo quale sarebbe un modo migliore per l'architettura questo?

"Bundling" I1e I2into I3offre una scorciatoia (?) O una sorta di zucchero di sintassi per ovunque tu voglia implementare entrambi.

Il problema con questo approccio è che non puoi impedire ad altri sviluppatori di implementare esplicitamente I1 e I2 fianco a fianco, ma non funziona in entrambi i modi - anche se : I3è equivalente a : I1, I2, : I1, I2non è equivalente a : I3. Anche se funzionalmente identici, una classe che supporta entrambi I1e I2non verrà rilevata come supporto I3.

Ciò significa che stai offrendo due modi per ottenere lo stesso risultato: "manuale" e "dolce" (con lo zucchero della sintassi). E può avere un impatto negativo sulla coerenza del codice. Offrendo 2 modi diversi per ottenere la stessa cosa qui, lì e in un altro posto si ottengono già 8 possibili combinazioni :)

void foo() {
    I1 something = new A();
    something = new B();
    something.SomeI1Function();
    something.SomeI2Function(); // we can't do this without casting first
}

OK, non puoi. Ma forse è in realtà un buon segno?

Se I1e I2implicare responsabilità diverse (altrimenti non sarebbe necessario separarle in primo luogo), allora forse foo()è sbagliato provare a far somethingeseguire due diverse responsabilità in una volta sola?

In altre parole, potrebbe essere esso foo()stesso a violare il principio della responsabilità singola e il fatto che richieda controlli di tipo casting e runtime per eseguirlo è una bandiera rossa che ci allarma.

MODIFICARE:

Se hai insistito per assicurarti che fooprendesse qualcosa che implementasse I1e I2, potresti passarli come parametri separati:

void foo(I1 i1, I2 i2) 

E potrebbero essere lo stesso oggetto:

foo(something, something);

Cosa fooimporta se sono la stessa istanza o no?

Ma se importa (ad es. Perché non sono apolidi), o pensi semplicemente che sembri brutto, potresti invece usare i generici:

void Foo<T>(T something) where T: I1, I2

Ora i vincoli generici si occupano dell'effetto desiderato senza inquinare il mondo esterno con nulla. Questo è C # idiomatico, basato su controlli in fase di compilazione, e nel complesso sembra più giusto.

Vedo in I3 : I2, I1qualche modo uno sforzo per emulare i tipi di unione in un linguaggio che non lo supporta immediatamente (C # o Java no, mentre i tipi di unione esistono in linguaggi funzionali).

Cercare di emulare un costrutto che non è realmente supportato dalla lingua è spesso ingombrante. Allo stesso modo, in C # è possibile utilizzare metodi di estensione e interfacce se si desidera emulare i mixin . Possibile? Sì. Buona idea? Non ne sono sicuro.

Se ci fosse un'importanza particolare nell'avere una classe implementare entrambe le interfacce, allora non vedo nulla di male nel creare una terza interfaccia che eredita da entrambe. Tuttavia, starei attento a non cadere nella trappola di cose ingegneristiche. Una classe potrebbe ereditare dall'una o dall'altra o da entrambi. A meno che il mio programma non abbia avuto molte classi in questi tre casi, è un po 'troppo creare un'interfaccia per entrambi, e certamente non se quelle due interfacce non avessero relazione l'una con l'altra (nessuna interfaccia IComparableAsSerializable per favore).

Ti ricordo che puoi creare anche una classe astratta che eredita da entrambe le interfacce e puoi usare quella classe astratta al posto di I3. Penso che sarebbe sbagliato dire che non dovresti farlo, ma dovresti almeno avere una buona ragione.

Le interfacce vuote sono generalmente considerate cattive pratiche

Non sono d'accordo. Leggi le interfacce dei marker .

Mentre un'interfaccia tipica specifica funzionalità (sotto forma di dichiarazioni di metodi) che una classe di implementazione deve supportare, un'interfaccia marker non deve farlo. La semplice presenza di tale interfaccia indica un comportamento specifico da parte della classe di implementazione.