Cosa succede se la mia classe nidificata estende un'altra classe da un altro pacchetto?

Question

Cosa succede se la mia classe nidificata estende un'altra classe da un altro pacchetto?

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

3

Sono dubbi che questo design sia OK, potrebbe esserci un modo per farlo meglio? Il caso è che ho bisogno di una classe che verrebbe utilizzata in una sola ed unica classe e basta. Ma questa classe ha bisogno di ereditare da un'altra, che è in un altro pacchetto. Questo non suona come per me.

public class User {

private class SpecificParser extends BaseParser {} // BaseParser.java is in another package

}

Creo semplicemente SpecificParser come classe separata, ma non voglio farlo anche perché l'unico consumatore è una classe User .

design java

posta Eugene 03.09.2013 - 15:56

fonte

2 risposte

2

Non penso che il fatto che SpecificParser sia una classe annidata è un problema in sé. Quello che dovresti pensare è se in generale sia ok avere una dipendenza dal pacchetto contenente BaseParser . Ad esempio, se ciò comportasse una dipendenza circolare tra i due pacchetti, ciò sarebbe negativo. Dal suo aspetto, in questo caso non dovrebbe essere un problema, dal momento che è improbabile che un parser dipenda da un utente. :)

risposta data 03.09.2013 - 16:03

fonte

Leggi altre domande sui tag design java

Perché lo strumento offre di cambiare il codice - solo perché può? Kafka, è possibile ottenere l'offset del messaggio dopo la produzione?

score 2 · Accepted Answer

Ci sono due problemi a portata di mano. Il primo è "Estendi una classe da un altro pacchetto in un design diverso di un pacchetto diverso" il secondo riguarda le dipendenze.

Versione breve, a posto.

Non c'è nulla di fondamentalmente sbagliato nell'estendere una classe da un altro pacchetto in un altro pacchetto. In effetti, a volte questo è il modo solo di farlo. Non è possibile estendere la classe HashMap e posizionare la classe risultante in java.util .

Considera le classi in java.lang che vengono estese in altre classi dappertutto - Object , Number , Thread .

In molte cassette di framework di terze parti, si avrà un barattolo sigillato che impedisce di inserire una classe in quello spazio dei nomi, ma è intesa per essere estesa in altro codice.

Non c'è niente di sbagliato nell'estendere una classe da qualche altro pacchetto. Il fatto che la classe sia una classe interna privata rende questo problema ancora meno problematico (poiché nasconde i dettagli di implementazione all'interno di se stesso).

Le dipendenze sono un incubo - e con cui dobbiamo convivere. Ci sono due parti in questo. C'è il 'tu hai creato una dipendenza da User a BaseParser '. Dato il nome di BaseParser , è abbastanza chiaro che è destinato ad essere esteso. Devi solo assicurarti di documentare tale dipendenza e avere i test appropriati per assicurarti che funzioni nel modo desiderato.

Ci sarà una dipendenza in un modo o nell'altro. Probabilmente è meglio avere qualcosa che dipende da un BaseSomething rispetto ad una classe casuale in un altro pacchetto che dipende da qualche altra classe specifica.

Vuoi anche evitare una dipendenza circolare. Non è troppo un grosso problema in termini di "non farlo mai perché spezzerà le cose", ma piuttosto "evita di farlo perché crea situazioni in cui cambierai in A che si interromperà qualcosa in B, e il fixing di B spezzerà qualcos'altro in A. C'è molto scritto su questo argomento. Due esempi da Stack Overflow: