Rilevazione riflessiva di una classe interna in un'API

0

Lascia che te lo chieda, poiché questo mi disturba già da un po 'ma sembra essere soggettivamente la soluzione migliore per il mio problema, se la scoperta riflessiva di una classe interna per scopi API è una cattiva idea ?

In primo luogo, lascia che ti spieghi cosa intendo dicendo "scoperta riflessiva" e tutto il resto.

Sto abbozzando un'API per un sistema di database Java, che sarà centrata su entità basate su blocchi (non chiedermi cosa significhi - è una lunga storia) e quelle entità può essere letto e restituito al codice Java come oggetti suddivisi in sottoclassi dalla classe Entity .

Ho una classe Entity.Factory , che, per mezzo di interfacce fluenti, accetta un argomento Class<? extends Entity> e poi, usa un'istanza di Section.Builder , Property.Builder , o qualunque builder l'entità abbia, per dirla nello spazio di archiviazione back-end.

L'idea di registrare tutti i tipi di entità e i loro builder non mi attrae, quindi ho pensato che la soluzione più vicina al problema che sarebbe bastato alle mie esigenze di progettazione sarebbe stata scoprire, usando la riflessione, tutte le classi interne di Entity classi e trova una che si chiama Builder .

In cerca di informazioni approfondite :) E se mi mancassero alcuni importanti dettagli di progettazione (che potrebbero accadere mentre cercavo di rendere questa domanda il più concisa possibile), dimmelo e li aggiungerò.

    
posta wassup 16.08.2014 - 11:47
fonte

1 risposta

1

Forse stai guardando il problema nel modo sbagliato.

Non dovresti partire da una sottoclasse di Entità e trovare il Costruttore associato per riflessione. Invece, dovresti iniziare da un'istanza di un Builder e fargli costruire l'Entità che desideri.

Non so come usi la tua fabbrica. Ad esempio, invece di chiamare factory.create (Section.class) potresti chiamare factory.create (new Section.Builder ()). Avrebbe senso?

    
risposta data 21.08.2014 - 23:42
fonte

Leggi altre domande sui tag