verificări de date în getter / setter sau în altă parte?

voturi
9

Mă întreb dacă este o idee bună de a face verificări în getters și setteri , sau în altă parte în codul.

Acest lucru ar putea surprinde să fii atunci când vine vorba de optimizări și accelerarea codului, cred că nu ar trebui să facă verificări în getters și setteri, dar în cazul în care codul de bază actualizarea fișierelor sau baza de date. Greșesc?

Întrebat 05/08/2008 la 20:51
sursa de către utilizator
În alte limbi...                            


8 răspunsuri

voturi
13

Ei bine, unul dintre reaons ce clase conțin de obicei privat membri cu setteri publice / get este exact, deoarece acestea pot verifica datele.

Dacă aveți un număr decât poate fi între 1 și 100, i-ar pune cu siguranta ceva în setter care validează faptul că și atunci poate arunca o excepție, care este prins de cod. Motivul este simplu: Dacă nu o faci în setter, trebuie să ne amintim că 1-100 limitare de fiecare dată când îl setați, ceea ce duce la un cod multiplicată sau când îl uitați, aceasta duce la o stare nevalidă.

În ceea ce privește performanța, sunt cu Knuth aici:

„Ar trebui să uităm despre eficiență mici, să zicem circa 97% din timp. Optimizarea prematură este rădăcina tuturor relelor“

Publicat 05/08/2008 la 20:59
sursa de către utilizator

voturi
4

@Terrapin, re:

Dacă tot ce trebuie este o grămadă de [simplu set publice / get] proprietăți ... acestea ar putea fi la fel de bine domenii

Proprietăți au alte avantaje față de domenii. Sunt un contract mai explicit, sunt serializate, ele pot fi depanate mai târziu, ei sunt un loc frumos pentru extinderea prin moștenire. Sintaxa clunkier este o complexitate accidentală - .net 3.5, de exemplu, depaseste aceasta.

O comună (și eronată) practică este de a începe cu câmpurile publice, și le transformă în proprietăți mai târziu, pe o bază „după cum este necesar“. Acest lucru rupe contractul cu cineva care consumă clasa ta, asa ca cel mai bine este să începeți cu proprietăți.

Publicat 08/08/2008 la 01:07
sursa de către utilizator

voturi
3

Depinde.

În general, codul ar trebui să eșueze rapid. În cazul în care valoarea poate fi stabilită prin mai multe puncte în codul și validați numai pe după recuperarea valorii, bug-ul pare a fi în codul care face actualizarea. În cazul în care setteri validați de intrare, știi ce cod încearcă să stabilească valori invalide.

Publicat 05/08/2008 la 20:59
sursa de către utilizator

voturi
3

Din perspectiva de a avea codul de mai mentenabil, cred că ar trebui să faci la fel de mult ca tine poate de validare în setter unei proprietăți. În acest fel nu va fi cache sau în alt mod care se ocupă cu date incorecte.

La urma urmei, asta este ceea ce proprietăți sunt destinate. Dacă tot ce trebuie este o grămadă de proprietăți, cum ar fi ...

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

... acestea ar putea fi la fel de bine domenii

Publicat 05/08/2008 la 20:59
sursa de către utilizator

voturi
1

Încerc să nu lăsați niciodată obiectele mele introduceți o stare incorectă, deci setter cu siguranta ar avea de validare precum și orice metode care schimba starea. În acest fel, nu trebuie să vă faceți griji că obiectul am de-a face cu nu este validă. Dacă vă păstrați metodele de validare ca limite, atunci nu trebuie să vă faceți griji cu privire la cadrele de validare și apeluri de metode IsValid () presărat peste tot.

Publicat 23/09/2008 la 20:44
sursa de către utilizator

voturi
1

Îmi place să pună în aplicare IDataErrorInfo și a pus logica mea de validare în eroare și acest [ColumnName] proprietăți. În acest fel , dacă doriți să verificați dacă programatică există o eroare puteți testa pur și simplu oricare dintre aceste proprietăți în cod, sau puteți preda validarea off la legare în Web Forms, Windows Forms sau WPF datelor.

„ValidatesOnDataError“ proprietate de legare WPF face din acest deosebit de ușor.

Publicat 07/08/2008 la 23:24
sursa de către utilizator

voturi
1

S-ar putea să verificați domeniul Design Motivat , de Eric Evans. DDD are această noțiune a unei specificații:

... explicit VALUE-predicat ca OBIECTE în scopuri de specialitate. O SPECIFICAȚIE este un predicat care determină dacă un obiect are sau nu îndeplinește anumite criterii.

Cred că lipsa de rapid este un lucru, celălalt este în cazul în care pentru a păstra logica de validare. Domeniul este locul potrivit pentru a păstra logica și cred că un obiect specificație sau o metodă valida obiectele de domeniu ar fi un loc bun.

Publicat 05/08/2008 la 21:03
sursa de către utilizator

voturi
1

Validarea trebuie să fie capturat separat de getteri sau setteri într-o metodă de validare. În acest fel, în cazul în care validarea trebuie să fie reutilizate pe mai multe componente, acesta este disponibil.

Când setter este numit, un astfel de serviciu de validare ar trebui utilizat pentru a steriliza intrare în obiect. În acest fel, știi toate informațiile stocate într-un obiect este valabil în orice moment.

Nu aveți nevoie de nici un fel de validare pentru getter, deoarece informațiile cu privire la obiectul este deja de încredere să fie valabile.

Nu salvați de validare până când o actualizare a bazei de date !! Este mai bine să eșueze rapid .

Publicat 05/08/2008 la 20:55
sursa de către utilizator

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