Cosa c'è di sbagliato nel restituire hashtable dal metodo pubblico e quando ha senso farlo?

Utilizza una classe definita meglio come tipo di ritorno di una tabella hash che contiene un numero arbitrario di valori come coppie nome / valore.

1. Il primo e più importante punto è: la manutenibilità. Osservando il codice, un nuovo programmatore non può mai dire quali sono i valori restituiti dal metodo. Se una persona nuova non capisce questo guardando il codice, il codice non sarà utile e soggetto a errori ogni volta che qualcuno aggiungerà più chiavi / valori a quei dati o migliorerà l'applicazione.

2. I metodi sono contratti tra il chiamante e il servizio. La cosa più importante in un metodo è il loro input e output. Questo input e output dovrebbero essere facilmente leggibili e comprensibili e auto-documentabili. Se si utilizza una classe Persona come valore di ritorno che ha nome, cognome, età - È auto-documentante. Se si genera un Javadoc per questo, l'utente può navigare tra le classi per capirlo meglio. Se usi una tabella hash, devi o spiegarla nei commenti che nessuno leggerà o aggiornerà quando le cose cambiano.

3. Non puoi utilizzare generici come HashMap<String,String> nel caso in cui desideri aggiungere un numero (ad esempio età) all'istruzione return. Se non si utilizzano i generici, sarà necessario eseguire il cast avanti e indietro tra l'oggetto e il tipo effettivo. Puoi salvarlo se usi la digitazione dinamica.

4. Inoltre ci sono più possibilità di errori di runtime rispetto alla cattura dei problemi in fase di compilazione. Ad esempio, se qualcuno cancella una voce dall'hashmap e uno dei vecchi chiamanti si aspetta la voce, il client non riesce durante il runtime. È sempre meglio cogliere questo problema in fase di compilazione.

5. Sarà difficile restituire un tipo immutabile se si desidera utilizzare hashmap come tipo restituito e così via. Ma se usi un utente definito del tuo tipo, puoi controllarlo.

Si sarà tentati di usare una hashmap come tipo di ritorno perché è possibile evitare di creare un paio di classi all'inizio, ma sarà un incubo mantenere il codice in futuro. Vai orientato agli oggetti !!!!

Uno dei problemi sarebbe che in molti casi, la chiave per la tabella hash sarebbe una stringa. Quindi i consumatori del metodo dovrebbero sapere in anticipo quali chiavi usare per estrarre i dati. Ciò darebbe la possibilità di errori dovuti a errori ortografici durante l'accesso ai dati.

Un altro inconveniente è la rideterminabilità. Se in seguito deciderai di cambiare il nome di un membro, avrai un sacco di stringhe magiche che devono anche cambiare. È molto più semplice rinominare un membro della classe usando gli strumenti di refactoring forniti dagli IDE più buoni. Con una tabella hash probabilmente dovresti eseguire un'operazione di ricerca / sostituzione su tutti i file di origine che potrebbe essere problematico.

Infine, perderai il controllo del tempo di compilazione dell'accesso membro, sia in termini di nome che di tipo. Quest'ultimo non è un problema se la tua tabella hash contiene solo un tipo di oggetto, ma se contiene molti (anche nella stessa catena gerarchica) vuoi veramente sfruttare il sistema di tipi della tua lingua e ottenere il tempo di compilazione per controllarlo. Nella maggior parte degli IDE avrai un qualche tipo di funzionalità di intelligenza / completamento automatico: questi funzionano guardando il sistema dei tipi, ma non saranno in grado di aiutarti con i tasti tabella hash.

Come per le volte in cui sarebbe appropriato per restituire una tabella hash (o un'altra raccolta di coppie di valori chiave), la userai quando entrambi i valori e le chiavi non sono noti al momento della compilazione. Ad esempio, se hai un metodo che analizza una stringa di query e restituisce le chiavi & valori corrispondenti, una tabella hash sarebbe una buona scelta. In questo caso vorresti anche pensare di restituire una sorta di tabella di hash immutabile o di sola lettura.

Modifica - La maggior parte dei punti sollevati in questa risposta cessano di essere applicati quando parli di lingue dinamiche:)

L'argomento più importante contro questo sarebbe che stai esponendo troppe informazioni al consumatore. Il codice consumante deve solo sapere che si tratta di una raccolta di valori-chiave (dizionario) di qualche tipo; se è implementato come una hashmap, una lista di associazioni, un trie o altro, è relativamente poco interessante. Quindi il modo corretto sarebbe quello di restituire tramite un'interfaccia adatta ( IDictionary , o qualunque altra lingua prescelta usi) invece che per tipo effettivo.

Tutto ciò presupponendo che sia effettivamente necessario un dizionario per rappresentare i dati, ovvero i dati sono costituiti da coppie chiave / valore, in cui le chiavi sono univoche nel set di dati e non possono essere corrette in fase di compilazione. Se hai chiavi note, dovresti creare un tipo corretto (o diversi, se necessario) per i tuoi dati. Si tratta di considerare le chiavi stesse come parte dei dati o parte del codice.

Modifica :

Per chiarire, sto usando il termine dizionario per indicare il tipo più generico di struttura di dati chiave-valore qui; Non intendo alcuna implementazione specifica della lingua come dict di Python o Dictionary di .NET.

Una domanda che mi chiedo è "le chiavi cambiano in questo dizionario?" Se sono costanti, si dovrebbe restituire un oggetto o altra struttura di dati appropriata. Se sono dinamici, potresti voler restituire una sorta di struttura di stile del dizionario. Infine, se ci sono alcune chiavi che saranno costanti e alcuni set di chiavi dinamiche sconosciute, potresti voler restituire una struttura di dati ibrida che includa alcuni valori fissi e qualche sorta di dizionario per l'overflow.