Un getter dovrebbe lanciare un'eccezione se il suo oggetto ha uno stato non valido?

Mi capita spesso di imbattermi in questo problema, soprattutto in Java, anche se penso che sia un problema OOP generale. Cioè: sollevare un'eccezione rivela un problema di progettazione.

Supponiamo che io abbia una classe che ha un String namecampo e un String surnamecampo.

Quindi utilizza quei campi per comporre il nome completo di una persona al fine di visualizzarlo su una sorta di documento, ad esempio una fattura.

public void String name;
public void String surname;

public String getCompleteName() {return name + " " + surname;}

public void displayCompleteNameOnInvoice() {
    String completeName = getCompleteName();
    //do something with it....
}

Ora voglio rafforzare il comportamento della mia classe lanciando un errore se displayCompleteNameOnInvoiceviene chiamato prima che il nome sia stato assegnato. Sembra una buona idea, vero?

Posso aggiungere un getCompleteNamemetodo per aumentare le eccezioni al metodo. Ma in questo modo sto violando un contratto "implicito" con l'utente della classe; in generale i getter non dovrebbero generare eccezioni se i loro valori non sono impostati. Ok, questo non è un getter standard poiché non restituisce un singolo campo, ma dal punto di vista dell'utente la distinzione potrebbe essere troppo sottile per pensarci.

Oppure posso generare l'eccezione dall'interno di displayCompleteNameOnInvoice. Ma per fare ciò dovrei testare direttamente nameo surnamecampi e così facendo violerei l'astrazione rappresentata da getCompleteName. È responsabilità di questo metodo verificare e creare il nome completo. Potrebbe persino decidere, basando la decisione su altri dati, che in alcuni casi è sufficiente il surname.

Quindi l'unica possibilità sembra cambiare la semantica del metodo getCompleteNamea composeCompleteName, che suggerisce un comportamento più 'attivo' e, con essa, la capacità di un'eccezione.

È questa la migliore soluzione di design? Sono sempre alla ricerca del miglior equilibrio tra semplicità e correttezza. Esiste un riferimento di progettazione per questo problema?

Non consentire la costruzione della tua classe senza assegnare un nome.

La risposta fornita da DeadMG in qualche modo lo inchioda, ma lasciatemi esprimere la frase in modo leggermente diverso: Evitare di avere oggetti con stato non valido. Un oggetto dovrebbe essere "intero" nel contesto del compito che svolge. O non dovrebbe esistere.

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

Non hai un oggetto con uno stato non valido.

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

Quindi, la domanda per questa parte è "perché permetti a nome o cognome di essere nulli?" Se questo non è qualcosa che è valido nella classe per farlo funzionare correttamente, non permetterlo. Avere un costruttore o un costruttore che convalida correttamente la creazione dell'oggetto e, se non è corretto, sollevare il problema a quel punto. Puoi anche utilizzare una delle @NotNullannotazioni esistenti per aiutare a comunicare che "questo non può essere nullo" e applicarlo nella codifica e nell'analisi.

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

Getter che fanno di più.

C'è un bel po 'fuori su questo argomento. Hai quanta logica in Getter e cosa dovrebbe essere consentito all'interno di getter e setter? da qui e getter e setter eseguono ulteriore logica su Stack Overflow. Questo è un problema che si presenta ancora e ancora nel design di classe.

Il nucleo di questo deriva da:

in generale i getter non dovrebbero generare eccezioni se i loro valori non sono impostati

E hai ragione. Non dovrebbero. Dovrebbero apparire "stupidi" al resto del mondo e fare ciò che ci si aspetta. Inserire troppa logica lì dentro porta a problemi in cui viene violata la legge del minimo stupore. E ammettiamolo, non vuoi davvero avvolgere i getter con un try catchperché sappiamo quanto amiamo farlo in generale.

Ci sono anche situazioni in cui è necessario utilizzare un getFoometodo come il framework JavaBeans e quando si ha qualcosa dalla chiamata EL che si aspetta di ottenere un bean (in modo che <% bar.foo %>effettivamente chiama getFoo()nella classe - mettendo da parte '' il bean dovrebbe fare la composizione o dovrebbe che deve essere lasciato alla vista? 'perché si possono facilmente trovare situazioni in cui l'una o l'altra può essere chiaramente la risposta giusta)

Comprendi anche che è possibile specificare un determinato getter in un'interfaccia o far parte dell'API pubblica precedentemente esposta per la classe che viene refactored (una versione precedente aveva appena "completeName" che veniva restituito e un refactoring si era rotto in due campi).

Alla fine del giorno...

Fai la cosa più facile da ragionare. Trascorrerai più tempo a mantenere questo codice di quanto impiegherai a progettarlo (anche se meno tempo impieghi a progettare, più tempo impiegherai a mantenere). La scelta ideale è progettarla in modo che non ci vorrà molto tempo per mantenerla, ma non stare lì a pensarci nemmeno per giorni - a meno che questa non sia davvero una scelta progettuale che avrà giorni di implicazioni in seguito .

Cercare di rimanere con la purezza semantica dell'essere getter private T foo; T getFoo() { return foo; }ti metterà nei guai ad un certo punto. A volte il codice non si adatta a quel modello e le contorsioni che si attraversano per cercare di mantenerlo in questo modo non hanno senso ... e alla fine rende più difficile la progettazione.

Accetta a volte che gli ideali del design non possano essere realizzati nel modo desiderato nel codice. Le linee guida sono linee guida, non catene.

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

getCompleteNamenon genera un'eccezione se i nomi non sono inizializzati e lo displayCompleteNameOnInvoicefa.

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ò a cui piace credere, "evitare oggetti non validi" non è spesso una soluzione pratica.

La risposta è:

Sì dovrebbe.

Esempio semplice: FileStream.Lengthin C # /. NET , che genera NotSupportedExceptionse il file non è ricercabile.

Hai l'intero nome del controllo a testa in giù.

getCompleteName()non deve sapere quali funzioni lo utilizzeranno. Pertanto, non avere una namechiamata quando displayCompleteNameOnInvoice()non è getCompleteName()una responsabilità.

Ma nameè un chiaro prerequisito per displayCompleteNameOnInvoice(). Pertanto, dovrebbe assumersi la responsabilità di controllare lo stato (o dovrebbe delegare la responsabilità del controllo a un altro metodo, se si preferisce).