Può influire sulle prestazioni?
Certo, lo sarà.
Se stai convalidando qualcosa, hai un sovraccarico lì. A volte questo overhead è significativo, altre volte è trascurabile.
Devo convalidare il setter?
Se la convalida sul setter della proprietà fa male alla tua performance, forse dovresti eseguire la validazione solo quando strettamente necessario, come quando lo stai persistendo in un database (qualcosa come un metodo isValid ). Lo svantaggio di questo approccio è che potresti avere oggetti non validi in giro.
C'è anche una terza scuola di pensiero qui:
- Oggetti mutevoli che non sono mai validi (convalida sempre sul setter, come il tuo scenario)
- Oggetti mutabili che possono trovarsi in uno stato non valido (convalidare solo se necessario, come ho detto sopra)
- Oggetti immutabili che non possono essere non validi (se non è valido non costruisci affatto l'oggetto)
Uno svantaggio con il primo, quello che stai attualmente utilizzando, è che potresti eseguire la convalida quando non è necessario.
Tutti hanno pro e contro, quale scegliere dipende molto dal tuo scenario e dal tuo background di (colleghi).
La validazione deve essere eseguita sull'oggetto stesso?
Questo è ancora più discutibile. La separazione dei dati dalla logica aziendale viene spesso definita come modello di dominio anemico . Un famoso obiettore del modello di dominio anemico è Martin Fowler , che in questo particolare argomento non sono d'accordo con lui, ma va bene , è il mio parere:)
Sto semplificando troppo qui, ma la principale differenza tra lasciare che il tuo dominio sia anemico e non quello è più conforme al puro teorico OOP e, all'inizio, richiede meno sforzo per progettare e mantenere; l'altro fa una migliore separazione delle preoccupazioni ed è molto meglio quando si ha a che fare con la concorrenza (dato che gli oggetti sono senza stato).
Questo argomento è un ottimo spunto di riflessione. Ti suggerisco di lasciare tutto così com'è se ti trovi in uno scenario di risoluzione dei problemi maggiore; grandi cambiamenti sullo status quo potrebbero non essere salutari se il tempo non è corretto.
P.S.
Essendo specifico per il tuo ORM, a seconda della lingua o del framework che stai utilizzando, il tuo ORM può trovare un modo per serializzare / deserializzare senza usare getter o setter.