Ik zou het volgende vermijden
sql.append("SELECT * FROM ").append("dogs_table");
sql.append(" WHERE ").append(colName).append("='");
sql.append(colValue).append("'");
en gebruik in plaats daarvan een PreparedStatement
met de bijbehorende methodes voor het instellen van parameters (setString() ) etc. Dit voorkomt problemen met waarden voor colValue met aanhalingstekens en SQL-injectie-aanvallen (of meer in het algemeen, colValue wat SQL-syntaxis vormt).
Ik zou nooit een null teruggeven als de verzameling alleen maar leeg was. Dat lijkt erg contra-intuïtief en volkomen onverwacht vanuit het oogpunt van de klant.
Ik zou niet aanraden om een null in foutcondities te retourneren, omdat je klant hier expliciet op moet controleren (en waarschijnlijk zal vergeten). Ik zou indien nodig een lege verzameling retourneren (dit kan analoog zijn aan uw opmerking over een null-object), of meer waarschijnlijk een uitzondering maken (afhankelijk van de omstandigheden en de ernst). De uitzondering is handig omdat deze informatie bevat over de opgetreden fout. Null vertelt je niets.
Wat moet je doen als je een probleem tegenkomt tijdens het bouwen van een Dog voorwerp ? Ik denk dat dat afhangt van hoe robuust en veerkrachtig je wilt dat je applicatie is. Is het een probleem om een subset van Dog . te retourneren? s, of zou het volledig catastrofaal zijn en moet u dit melden? Dat is een aanvraagvereiste (ik heb in het verleden voor beide scenario's moeten zorgen - best-effort of alles-of-niets ).
Een paar observaties. Ik zou HashMap
gebruiken in plaats van de oude Hashtable (gesynchroniseerd voor alle toegang en, belangrijker nog, geen goede Collection - als je een Collection hebt je kunt het doorgeven aan elke andere methode die elke . verwacht Collection ), en StringBuilder
via StringBuffer om soortgelijke redenen. Geen groot probleem, maar het weten waard.