verifiche di dati in getter / setter o altrove?

voti
9

Mi chiedo se è una buona idea per fare verifiche di getter e setter , o altrove nel codice.

Questo potrebbe sorprendere di essere quando si tratta di ottimizzazioni e accelerare il codice, penso che non si dovrebbe fare verifiche in getter e setter, ma nel codice in cui si sta aggiornando i file o database. Ho sbagliato?

È pubblicato 05/08/2008 alle 20:51
fonte dall'utente
In altre lingue...                            


8 risposte

voti
13

Ebbene, una delle reaons perché classi di solito contengono membri privati ​​con getter / setter pubblici è esattamente perché possono verificare i dati.

Se si dispone di un numero che può essere compreso tra 1 e 100, avrei sicuramente messo qualcosa nel setter che convalida che e poi forse un'eccezione che viene catturato dal codice. La ragione è semplice: se non lo fai nel setter, si deve ricordare che 1 a 100 limitazione ogni volta che lo si imposta, che porta a codice duplicato o quando lo si dimentica, porta a uno stato non valido.

Per quanto riguarda le prestazioni, io sono con Knuth qui:

"Dobbiamo dimenticare le piccole efficienze, dire circa il 97% del tempo: l'ottimizzazione prematura è la radice di tutti i mali".

Risposto il 05/08/2008 a 20:59
fonte dall'utente

voti
4

@Terrapin, re:

Se hai a disposizione solo un po 'di [semplice insieme pubblico ottenere /] proprietà ... che potrebbe anche essere campi

Proprietà hanno altri vantaggi rispetto campi. Si tratta di un contratto più esplicito, sono serializzati, possono eseguire il debug in seguito, sono un bel posto per estensione attraverso l'ereditarietà. La sintassi clunkier è una complessità accidentale - NET 3.5 per esempio supera questo.

Un comune (e imperfetto) la pratica è di iniziare con campi pubblici, e li trasformano in proprietà in seguito, su base 'se necessario'. Questo rompe il contratto con chiunque consuma la classe, quindi è meglio iniziare con le proprietà.

Risposto il 08/08/2008 a 01:07
fonte dall'utente

voti
3

Dipende.

In generale, il codice dovrebbe fallire veloce. Se il valore può essere impostato da più punti del codice e validare solo dopo il recupero del valore, il bug sembra essere nel codice che fa l'aggiornamento. Se il setter convalidano l'input, si sa quale codice sta cercando di impostare valori non validi.

Risposto il 05/08/2008 a 20:59
fonte dall'utente

voti
3

Dal punto di vista di avere il codice più mantenibile, penso che si dovrebbe fare il più convalida, come si può nel setter di una proprietà. In questo modo non sarà memorizzazione nella cache o altrimenti si tratta di dati non validi.

Dopo tutto, questo è ciò che le proprietà sono pensati per. Se hai a disposizione solo un po 'di immobili come ...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

... potrebbero anche essere i campi

Risposto il 05/08/2008 a 20:59
fonte dall'utente

voti
1

Cerco di non lasciare che i miei oggetti entrano in uno stato non valido, quindi setter sicuramente avrebbero convalida e tutti i metodi che cambiano stato. In questo modo, non ho mai si deve preoccupare che l'oggetto ho a che fare non è valido. Se si mantiene i vostri metodi da confini di convalida, quindi non dovrete mai preoccuparvi di quadri di convalida e chiamate di metodo IsValid () cosparsi in tutto il luogo.

Risposto il 23/09/2008 a 20:44
fonte dall'utente

voti
1

Mi piace per implementare IDataErrorInfo e mettere la mia logica di convalida nel suo errore e questo [columnName] proprietà. In questo modo se si desidera controllare programmazione se c'è un errore si può semplicemente provare una di queste proprietà nel codice, oppure si può consegnare la convalida fuori per le associazione dati nel Web Form, Windows Form o WPF.

"ValidatesOnDataError" proprietà Binding di WPF rende particolarmente facile.

Risposto il 07/08/2008 a 23:24
fonte dall'utente

voti
1

Si potrebbe desiderare di check-out Domain Driven Design , da Eric Evans. DDD ha questa idea di una specifica:

... esplicito VALORE predicato come oggetti per scopi specializzati. Una specifica è un predicato che determina se un oggetto sia o non soddisfa alcuni criteri.

Credo che in mancanza veloce è una cosa, l'altro è dove tenere la logica per la convalida. Il dominio è il posto giusto per mantenere la logica e credo che una specifica oggetto o un metodo validate sui vostri oggetti di dominio sarebbe un buon posto.

Risposto il 05/08/2008 a 21:03
fonte dall'utente

voti
1

Convalida deve essere catturato separatamente dal getter o telai in un metodo di convalida. In questo modo se la convalida deve essere riutilizzati in più componenti, è disponibile.

Quando il setter viene chiamato, tale servizio convalida deve essere utilizzato per correggere l'input nell'oggetto. In questo modo si sa tutte le informazioni memorizzate in un oggetto è valida in tutti i tempi.

Non è necessario alcun tipo di convalida per il getter, in quanto le informazioni sul l'oggetto è già di fiducia per essere valido.

Non salvare la convalida fino a quando un aggiornamento del database !! E 'meglio non riuscire veloce .

Risposto il 05/08/2008 a 20:55
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more