Gestione delle eccezioni per gli attributi di classe in setter e costruttori [chiuso]

Question

Gestione delle eccezioni per gli attributi di classe in setter e costruttori [chiuso]

#1 da (4 voti)
#2 da (1 voti)

1

Vorrei discutere una domanda sulle migliori pratiche relative alla gestione delle eccezioni (ad es. in Java). Normalmente, quando si impostano gli attributi di una classe, controllo gli argomenti nei setter per la validità, e se gli argomenti non sono validi, lancio una IllegalArgumentException.

Oltre ai setter, a volte anche il costruttore della classe consente di impostare alcuni valori per gli attributi. Quindi devo anche verificare gli argomenti nel costruttore per la validità. Ciò, tuttavia, comporterebbe la duplicazione del codice. Posso solo pensare ad una soluzione per questo problema: invece di impostare direttamente il valore dell'attributo nel costruttore, chiamo il setter, che poi convalida anche il valore dato.

Tuttavia, poiché i setter sono pubblici, questo ha il problema che chiamerei un metodo sovrascrivibile all'interno del costruttore, il che è male. Per risolvere nuovamente questo problema, potrei rendere definitivi i setter, ma questo non l'ho mai visto.

Un'altra possibilità che potrei pensare, in teoria, è di avere un privato o molti metodi privati che controllano gli argomenti per la validità e che sono chiamati da entrambi i costruttori e setter. Ma questo porterebbe a un numero ancora maggiore di codice. Quali ritieni che siano le migliori pratiche per questo problema?

object-oriented exceptions class-design

posta Rolch2015 08.01.2016 - 01:19

fonte

2 risposte

Leggi altre domande sui tag object-oriented exceptions class-design

Posso realizzare un'implementazione closed-source da zero di una libreria con licenza GPL? [chiuso] Un client / server TCP è una buona soluzione per un sistema che può essere controllato da una GUI in esecuzione su più piattaforme?

score 4 · Answer 1

Ottima domanda, la tua impressione che non dovresti impostare i metodi setter come finale o privato è corretto. Devi consentire alle classi figlie di sovrascriverle quando necessario.

La migliore pratica è chiamare i metodi setter nel costruttore.

Se altre classi estendono la classe e sovrascrivono i metodi setter con le proprie convalide, il costruttore genitore chiamerà i metodi setter del figlio a condizione che l'istanza sia istanziata come classe figlio.

score 1 · Answer 2

To solve this problem again, I could make the setters final, but this I have never seen.

Penso che questa sia la soluzione appropriata.

Mi dispiace di non averlo mai visto prima, perché penso che i setter dovrebbero essere quasi sempre dichiarati final . Riesci a pensare ad una buona ragione per scavalcare un setter in una classe derivata? Qual è lo scopo di un setter? Assegna un valore a un attributo (si spera private ), probabilmente dopo aver verificato il nuovo valore. Che utile potrebbe essere ignorare questo? Non riesco a pensare a nessuna situazione in cui l'override del setter sarebbe nient'altro che un codice molto scadente. Quindi, sì, continua, rendili final .