Eviterei quanto segue
sql.append("SELECT * FROM ").append("dogs_table");
sql.append(" WHERE ").append(colName).append("='");
sql.append(colValue).append("'");
e invece usa un PreparedStatement
con i metodi di impostazione dei parametri associati (setString() ) ecc. Ciò eviterà problemi con i valori per colValue con virgolette e attacchi SQL injection (o più in generale, colValue formando una sintassi SQL).
mai restituire un null se la raccolta era semplicemente vuota. Sembra molto controintuitivo e del tutto inaspettato dal punto di vista del cliente.
Non consiglierei di restituire un null in condizioni di errore, poiché il tuo client deve verificarlo esplicitamente (e probabilmente lo dimenticherà). Se necessario, restituirei una raccolta vuota (questo potrebbe essere analogo al tuo commento relativo a un oggetto nullo) o più probabilmente genererebbe un'eccezione (a seconda delle circostanze e della gravità). L'eccezione è utile in quanto conterrà alcune informazioni relative all'errore riscontrato. Null non ti dice nulla.
Cosa dovresti fare se incontri un problema mentre costruisci un Dog oggetto? Penso che dipenda da quanto vuoi che sia robusta e resiliente la tua applicazione. È un problema restituire un sottoinsieme di Dog s, o sarebbe completamente catastrofico e devi segnalarlo? Questo è un requisito dell'applicazione (in passato ho dovuto soddisfare entrambi gli scenari - best-effort o tutto o niente ).
Un paio di osservazioni. Userei HashMap
piuttosto che la vecchia Hashtable (sincronizzato per tutti gli accessi e, soprattutto, non una vera e propria Collection - se hai una Collection puoi passarlo a qualsiasi altro metodo aspettandoti qualsiasi Collection ), e StringBuilder
su StringBuffer per ragioni simili. Non è un grosso problema, ma vale la pena conoscerlo.
