È cattiva pratica di codifica creare qualcosa in un get se non esiste?

Sì, conta. Secondo me, è generalmente una cattiva pratica creare qualcosa in una procedura che non è documentata come dotata dei poteri della creazione. Assegna alla procedura getOrCreate... o una procedura create... separata, quindi se desideri veramente , ottieni getOrCreate... che prima tenta get... , e se fallisce, chiama create... e quindi chiama get... .

L'utente della libreria probabilmente non si aspetta che la procedura get... venga creata se l'operazione get fallisce. Se improvvisamente scoprono che il loro test chiama get... ha creato un'intera tonnellata di dati, probabilmente saranno piuttosto sorpresi. E come lo puliscono? Cosa succede se scrivono codice pensando che riceveranno un errore se get... fallisce e vogliono gestire quel loro modo?

No, non è una "cattiva pratica". Finché tu e gli altri sviluppatori siete d'accordo sul fatto che vuoi che funzioni, va bene. Dopotutto, restituirebbe un account, che è quello che vuoi. Che l'account venga creato "sotto il cofano" è irrilevante per il chiamante.

Se getAccount() può sempre restituire un account, quindi dal punto di vista del chiamante, l'account esiste ed è sempre esistito. Non è necessario per getAccount() creare 'qualcosa'. L'account non deve essere memorizzato ovunque finché non è diverso dall'account predefinito.

Ha più senso creare 3 metodi:

getAccount - > Quale ottiene l'account.

createAccount - > Crea un account.

getAccountAndCreateIfNeeded - > Scegli la tua denominazione;)

Perché la separazione: hai un metodo semplice per ottenere e creare. Questo è un chiaro metodo testabile per entrambi. Per getAccount non è un'eccezione per non trovare l'account. Quindi è sufficiente restituire false o qualcosa del genere, è previsto.

Quindi puoi usare quel valore di ritorno nella tua funzione raggruppata: getAccountAndCreateIfNeeded che ora è anche testabile, dovrebbe restituire sempre un account. Qualunque cosa tu chieda.

Tutti questi 3 metodi sono chiari, è esattamente chiaro cosa fanno e cosa restituiscono. Puoi stipulare accordi con la tua squadra ma questo tipo di eccezioni è terribile a lungo termine. Basta renderli molto chiari e non avrai problemi.

Dipende dalle circostanze.

Ad esempio, è possibile utilizzarlo per eseguire il caricamento / l'istanza lazy, rinviare il caricamento dei dati o la creazione di un'istanza finché non è effettivamente necessaria. Questo è normalmente ragionevole poiché salva risorse che potrebbero non essere necessarie (se la classe / i dati non sono mai necessari, non vengono mai caricati).

Tuttavia, in questo caso particolare, direi che avere un metodo chiamato getAccount che creerebbe un nuovo account se non esistesse non sarebbe una buona pratica. Se l'utente ha fornito alcune credenziali per identificare un determinato account e quell'account non è stato trovato, significa che l'utente non è ancora un cliente e dovrebbe avere un account creato per loro, o significa che le credenziali sono state digitate in modo errato e l'utente deve essere invitato a verificare di aver inserito ciò che intendevano inserire?

Se hai un metodo getAccount che crea un nuovo account se non è in grado di identificarne uno, non hai scelta in merito. Se dividi la creazione dell'account e l'account in metodi separati, allora hai molta più flessibilità nel decidere cosa fare se un tentativo di ottenere un account fallisce.