Va bene che le interfacce dipendano da classi concrete?

Sto creando un'interfaccia in Java per il gestore degli errori personalizzato.

Vuoi passare un oggetto errore argomento ma ho bisogno che sia figlio di Exceptionclasse.

Va bene usare il nome della mia classe definita in un'interfaccia?

Non renderà meno un'interfaccia in termini di non dipendere da alcuna implementazione?

Provo a fare qualcosa del genere:

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}

— nikachx
fonte

Stai cercando di chiedere se va bene ereditare un'altra classe in un'interfaccia?

— Snoop,

@StevieV No. Ho modificato la domanda, guarda.

— nikachx,

@AndresF. È solo un esempio e può essere applicato a qualsiasi linguaggio OO sull'uso delle classi nelle interfacce.

— nikachx,

Dimmi: fa CustomExceptionparte dell'implementazione o parte dell'interfaccia?

— user253751

@nikachx Non capisco cosa intendi per "sicuro". In che modo è Stringpiù sicuro di CustomException? Perché è importante se CustomException, a sua volta, ha altre dipendenze?

— Andres F.

Risposte:

In primo luogo devo sottolineare il fatto che CustomExceptionnon si estende Exceptionquindi non è davvero un Exception.

Detto ciò:

Se non ti interessa il principio di inversione di dipendenza , lascialo così com'è. È perfettamente accettabile che un'interfaccia dipenda da classi concrete, ad esempio molte interfacce dipendono da Stringo Objectquali sono classi concrete . Il fatto è che tendiamo a credere che le classi che appartengono a Java SDK siano più stabili (meno inclini a modifiche di rottura del codice) rispetto a quelle che scriviamo.

Nell'altra mano:

Se vuoi seguire il DIP (che ha innumerevoli vantaggi ed è la mia raccomandazione), allora devi fare una delle due cose:

opzione 1

Rendi CustomExceptionastratto
Mantieni void onError(CustomException ex)com'è

opzione 2

Crea CustomExceptionun'interfaccia
Mantieni void onError(CustomException ex)com'è

Con una di queste opzioni ti conformeresti al DIP, poiché l'interfaccia non dipenderà da nessuna classe concreta, ma solo dalle astrazioni.

In un'applicazione diretta dell'inversione di dipendenza, gli abstract sono di proprietà dei livelli superiori / politici. Questa architettura raggruppa i componenti di politica superiore e gli abstract che definiscono i servizi inferiori nello stesso pacchetto. I livelli di livello inferiore sono creati dall'ereditarietà / implementazione di queste classi o interfacce astratte . Martin, Robert C. (2003).

Sviluppo software agile, principi, modelli e pratiche. Prentice Hall. pagg. 127–131. ISBN 978-0135974445.

— Tulains Córdova
fonte

Non c'è molta differenza tra accettare una classe astratta o una classe concreta (non definitiva) e la differenza rispetto a un'interfaccia non è molto più di questo. Finché l'istanza viene passata come parametro e non codificata nella propria implementazione, si hanno le basi per DI.

— Jacob Raihle,

@JacobRaihle Cosa intendi con passare un'istanza codificata nell'implementazione?

— Tulains Córdova,

Ho detto "purché sia passato e non codificato". Ciò che intendo è che poiché l' Interfaceinterfaccia accetta un CustomExceptione lascia al chiamante il compito di fornirne uno, il chiamante è libero di fornire qualsiasi classe che si estenda CustomExceptionanche se CustomExceptionè una classe concreta - cosa che non sarebbe stata possibile se Interfacefosse in qualche modo responsabile della creazione esso. Questa inversione di controllo, più che lavorare con le interfacce (anche se certamente aiuta), è ciò che penso sia DI.

— Jacob Raihle,

@JacobRaihle "In un'applicazione diretta di inversione di dipendenza, gli abstract sono di proprietà dei livelli superiori / politici. Questa architettura raggruppa i componenti superiori / politici e gli estratti che definiscono servizi inferiori insieme nello stesso pacchetto. I livelli di livello inferiore vengono creati per eredità / implementazione di queste classi o interfacce astratte . " Martin, Robert C. (2003). Sviluppo software agile, principi, schemi e pratiche. Prentice Hall. pagg. 127–131. ISBN 978-0135974445.

— Tulains Córdova,

Qual è il punto di una classe astratta se è possibile fornire un valore predefinito ragionevole? Cosa perdi fornendo questo? Non limitarti a citare libri, pensa.

— Jacob Raihle,

Tulains ha ragione: le interfacce dipendono sempre da classi concrete. Hanno solo lo scopo di creare un contratto per le loro preoccupazioni. Tale contratto può comportare l'acquisizione e la restituzione di qualsiasi tipo di dati.

Ricorda che nelle lingue di livello superiore, anche i tipi primitivi non sono così primitivi. Quindi lavori comunque con tipi concreti!

— Sava B.
fonte

Suppongo per nome , intendi la classe vera e propria. Se si sta tentando di specificare il nome della classe di eccezione effettiva per inizializzare l'eccezione corrispondente tramite Reflection, questa non è la strada giusta da percorrere.

Se si desidera utilizzare una classe personalizzata in un'interfaccia, è possibile, ovviamente, utilizzare le proprie classi nelle proprie interfacce. Le classi diventano parte dell'interfaccia pubblica della tua libreria / API. Le strutture dei dati e le eccezioni sono un buon esempio delle classi che sono spesso utilizzate dalle interfacce.

Se è necessario utilizzare eccezioni diverse a seconda del contesto, è possibile che si desideri utilizzare generici.

— Arseni Mourzenko
fonte

No, non intendo la riflessione. Sì, come accennato, eccezioni e strutture di dati possono essere utilizzate nelle interfacce perché contengono solo dati e non sono piattaforma o dipendono in altro modo da altre classi. Grazie.

— nikachx,

Risposte che pongono le domande del PO ... Basta chiedere in un commento, quindi fornire la risposta.

— Snoop,

@StevieV: il primo paragrafo era più una domanda retorica. E come dimostrato dal commento del PO, ho effettivamente risposto alla domanda del PO.

— Arseni Mourzenko,