Ci sono situazioni in cui avere un "modello di dati" in cui tutte le entità sono istanze di Map<String, Object> avrebbe senso?
Come si spiega a qualcuno perché avere un tale "modello di dati" non è una buona idea? Sembra che per me sia un approccio assurdo, potrei mancare qualcosa?
Non è necessariamente una cattiva idea avere un modello di dati che è una mappa di stringhe chiave ai valori. Tuttavia spesso è una buona idea per astrarre quella dietro qualcosa di specifico del dominio, sia per dare un senso alle stringhe e agli oggetti sia per offrire un qualche punto per imporre vincoli che non sono evidenti dalle strutture dati sottostanti .
Se stai mappando Mappe allora sicuramente. Ma generalmente vuoi chiedere che cos'è una mappa di quello che stai modellando? Una mappa di gatti? una mappa di nodi? ecc.
Beh, alcuni esempi che ho trovato sono:
Map<String, Object> body = new HashMap<String, Object>(); //...
Map<String, Object> data = new HashMap<String, Object>(); //...
Map<String,Object> queryForMap(String sql, Object... args) //...
Per come la vedo io, si riduce a una domanda piuttosto semplice.
1234 - che tipo è? è ... Integer? o String, o Long, o forse, Double?
Quando c'è un contesto si può imparare sulla semantica dei dati, la domanda sopra è facile da rispondere. Ma cosa succede se non esiste un tale contesto? questo sembra essere un caso piuttosto comune nei quadri di passaggio dati.
Immagina di scrivere una libreria che trasmetta dati da varie fonti a diversi consumatori. Una sorgente può passare 1234 come stringa, un'altra come numero intero - non hai motivo di preferirne una rispetto a un'altra. Per quanto riguarda i consumatori, "sanno" che tipo si aspettano da una particolare fonte, ma perché dovrebbero "dirlo"?
Se segui pedissequamente il dogma mai un oggetto , potresti essere tentato di castare tutto arbitrariamente su un tipo che preferisci, come ad esempio String. Il problema però è che questo renderà la tua libreria più difficile da comprendere per i clienti, non sarà più facile: si romperanno la mente cercando di capire perché hai usato quel tipo e quali potrebbero essere le conseguenze.
Perché stringa? Ho intenzione di collegare l'origine dati che passa Double, cosa succederà? Ti convertirai? o ti romperesti? Inoltre, il mio consumatore si aspetta Double, significa che devo riconvertire? a proposito, come si converte, le impostazioni locali sono importanti? Oh e un'altra cosa, nel mio altro modulo ho intenzione di usare l'origine dati che passa a Long e il consumatore che si aspetta anche Long - potrebbero esserci problemi con questo?
Non ho usato librerie CSV, JDBC, JSON menzionate negli esempi qui sotto, ma in uno dei miei progetti passati c'è stato Map<String, Object> utilizzato in un framework di trasmissione dati proprietario e devo ammettere che, come il suo client, ho niente di cui lamentarsi.
Una cosa interessante che ho notato a proposito di quel framework proprietario è che non hanno intromesso i loro oggetti non tipizzati nel mio codice cliente. Hanno esposto i dati attraverso un livello API che me l'ha presentato usando i tipi di cui avevo bisogno.
In realtà ho solo imparato circa Map<String, Object> attraverso un metodo ausiliario "escape hatch" nella loro API. Non ricordo se il metodo javadocs abbia menzionato esplicitamente che è a scopo di debug, ma questa era la mia comprensione del perché è lì.
Se configuro l'origine dati in modo che passi String dove mi aspetto un intero, preferirei testare il Object che viene passato sotto il cofano invece di fissare criptico ClassCastException. Per questo, utilizzerei l'API "escape hatch".
Riassumendo, (1) Posso immaginare una libreria dove usare Object non tipizzato ha più senso che tirare fuori un tipo arbitrario dal nulla e (2) al codice client, sarei stato OK con quella libreria finchè ( 2a) l'API della libreria presenta i dati con il tipo necessario e (2b) c'è un modo conveniente per eseguire il debug di roba quando le cose vanno male.
Leggi altre domande sui tag java