Se un getter lancia un'eccezione se il suo oggetto ha uno stato non valido?

Non permettere che la tua classe sia costruita senza assegnare un nome.

La risposta fornita da DeadMG praticamente lo inchioda, ma lascia che lo esprima in modo un po 'diverso: evita di avere oggetti con stato non valido. Un oggetto dovrebbe essere "intero" nel contesto del compito che soddisfa. O non dovrebbe esistere.

Quindi se vuoi la fluidità, usa qualcosa come Builder Pattern . O qualsiasi altra cosa che sia una reificazione separata di un oggetto in costruzione rispetto alla "cosa reale", dove quest'ultimo è garantito per avere uno stato valido ed è quello che espone effettivamente le operazioni definite su quello stato (ad esempio getCompleteName ).

Non avere un oggetto con uno stato non valido.

Lo scopo di un costruttore o costruttore è di impostare lo stato dell'oggetto su qualcosa che sia coerente e utilizzabile. Senza questa garanzia, i problemi si presentano con uno stato non correttamente inizializzato negli oggetti. Questo problema si complica se hai a che fare con la concorrenza e qualcosa può accedere all'oggetto prima che tu abbia completamente finito di configurarlo.

Quindi, la domanda per questa parte è "perché stai permettendo che il nome o il cognome siano nulli?" Se questo non è qualcosa che è valido nella classe perché funzioni correttamente, non permetterlo. Avere un costruttore o un costruttore che validamente convalida la creazione dell'oggetto e, se non è giusto, sollevare il problema a quel punto. Potresti anche utilizzare una delle @NotNull annotazioni esistenti per comunicare che "questo non può essere nullo" e applicare in codifica e analisi.

Con questa garanzia, diventa molto più facile ragionare sul codice, su ciò che fa, e non deve gettare eccezioni in luoghi strani o mettere controlli eccessivi attorno alle funzioni getter.

Getter che fanno di più.

C'è un bel po 'là fuori su questo argomento. Hai Quanta logica in Getters e Cosa dovrebbe essere permesso all'interno di getter e setter? da qui e getter e setter che eseguono una logica aggiuntiva su Overflow dello stack. Questo è un problema che emerge ancora e ancora nel design della classe.

Il nucleo di questo viene da:

in general getters aren't supposed to throw exceptions if their values aren't set

E hai ragione. Non dovrebbero Dovrebbero sembrare "stupidi" nel resto del mondo e fare ciò che ci si aspetta. Mettendo troppa logica ci conduce a questioni in cui viene violata la legge del minimo stupore. E lasciamolo fronteggiare, davvero non vuoi fare il wrapping dei getter con un try catch perché sappiamo quanto ci piace farlo in generale.

Ci sono anche situazioni in cui devi usare un metodo getFoo come il framework JavaBeans e quando hai qualcosa da EL chiamando in attesa di ottenere un bean (in modo che <% bar.foo %> invochi effettivamente getFoo() nella classe, mettendo da parte 'il bean dovrebbe fare la composizione o dovrebbe essere lasciato alla vista? ', perché è facile arrivare a situazioni in cui l'una o l'altra può chiaramente essere la risposta giusta)

Comprendi anche che è possibile specificare un determinato getter in un'interfaccia o essere parte dell'API pubblica precedentemente esposta per la classe che viene sottoposta a refactoring (una versione precedente aveva solo 'completeName' che era stata restituita e un refactoring lo ha suddiviso in due campi).

Alla fine della giornata ...

Fai ciò che è più facile ragionare. Trascorrerai più tempo a conservare questo codice di quanto lo spenderesti a progettarlo (anche se meno tempo dedichi la progettazione, più tempo passerai a mantenere). La scelta ideale è progettarla in modo tale che non ci vorrà più tempo per mantenerla, ma non stare lì a pensarci per giorni - a meno che questa sia davvero una scelta di design che farà ha giorni di implicazioni più tardi.

Cercando di restare con la purezza semantica del getter che è private T foo; T getFoo() { return foo; } ti metterà nei guai a un certo punto. A volte il codice non si adatta a quel modello e le contorsioni che si verificano per cercare di mantenerla in quel modo non hanno senso ... e in ultima analisi rendono più difficile la progettazione.

Accetta a volte che gli ideali del design non possono essere realizzati nel modo in cui li desideri nel codice. Le linee guida sono linee guida, non catene.

Non sono un ragazzo di Java, ma questo sembra aderire a entrambi i vincoli che hai presentato.

getCompleteName non lancia un'eccezione se i nomi non sono inizializzati e displayCompleteNameOnInvoice lo fa.

public String getCompleteName()
{
    if (name == null || surname == null)
    {
        return null;
    }
    return name + " " + surname;
}

public void displayCompleteNameOnInvoice() 
{
    String completeName = getCompleteName();
    if (completeName == null)
    {
        //throw an exception.
    }
    //do something with it....
}

Sembra che nessuno stia rispondendo alla tua domanda.
A differenza di ciò che piace alla gente, "evitare oggetti non validi" non è spesso una soluzione pratica.

La risposta è:

Sì, dovrebbe.

Esempio semplice: FileStream.Length in C # /. NET , che genera NotSupportedException se il file non è ricercabile.

L'intero nome del controllo è capovolto.

getCompleteName() non deve sapere quali funzioni lo utilizzeranno. Pertanto, non avere name quando si chiama displayCompleteNameOnInvoice() non è responsabilità di getCompleteName() s.

Tuttavia, name è un chiaro prerequisito per displayCompleteNameOnInvoice() . Pertanto, dovrebbe assumersi la responsabilità di controllare lo stato (o dovrebbe delegare la responsabilità di controllare un altro metodo, se preferisci).