Va bene che le interfacce dipendano da classi concrete?

Question

Va bene che le interfacce dipendano da classi concrete?

Naviga le tue risposte

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

9

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

Vuoi passare un argomento error object ma ho bisogno che sia figlio di Exception class.

Va bene usare il mio nome di classe definito in un'interfaccia?

Non renderà meno un'interfaccia in termini di non dipendenza su qualsiasi implementazione?

Cerco di fare qualcosa di simile a questo:

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

public interface Interface {

    void onError(CustomException ex);

}

object-oriented design java interfaces

posta nikachx 23.10.2016 - 21:41

fonte

3 risposte

2

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 la presa e la restituzione di qualsiasi tipo di dati.

Ricorda che nei linguaggi di livello superiore, anche i tipi primitivi non sono così primitivi. Quindi stai lavorando con tipi concreti comunque!

risposta data 23.11.2016 - 19:18

fonte

0

Suppongo che per nome , intendi la classe stessa. Se si sta tentando di specificare la classe di eccezione name 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, naturalmente, utilizzare le proprie classi nelle proprie interfacce. Le classi diventano parti dell'interfaccia pubblica della tua libreria / API. Le strutture dati e le eccezioni sono un buon esempio delle classi che vengono spesso utilizzate dalle interfacce.

Se devi utilizzare diverse eccezioni a seconda del contesto, potresti essere interessato all'utilizzo di generici.

risposta data 23.10.2016 - 21:51

fonte

Leggi altre domande sui tag object-oriented design java interfaces

Consigli per una buona configurazione di sviluppo del server web [chiuso] Ultime modifiche alle API: come posso semplificare la transizione per gli utenti della biblioteca?

score 2 · Accepted Answer

Prima devo sottolineare il fatto che CustomException non estende Exception quindi non è realmente un Exception .

Detto questo:

Se non ti interessa il principio di inversione delle dipendenze , allora lasciatelo così com'è. È perfettamente OK perché un'interfaccia dipenda da classi concrete, ad esempio molte interfacce dipendono da String o Object che sono classi concrete . Il fatto è che tendiamo a credere che le classi che appartengono all'SDK Java siano più stabili (meno inclini alle modifiche al codice) di quelle che scriviamo.

D'altra parte:

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

Opzione 1

Crea CustomException astratto
Mantieni void onError(CustomException ex) come è

Opzione 2

Crea CustomException un'interfaccia
Mantieni void onError(CustomException ex) come è

Con una di queste opzioni si sarebbe conformi al DIP, poiché l'interfaccia non dipenderebbe da alcuna classe concreta, ma solo da astrazioni.

In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers. This architecture groups the higher/policy components and the abstracts that define lower services together in the same package. The lower-level layers are created by inheritance/implementation of these abstract classes or interfaces. Martin, Robert C. (2003).

Agile Software Development, Principles, > Patterns, and Practices. Prentice Hall. pp. 127–131. ISBN 978-0135974445.