Vă mulțumim pentru susținere

Verificări de date în Getter / Setter sau în altă parte?

Mă întreb dacă este o idee bună să faceți verificări în getters și setterii sau în altă parte a codului.

Acest lucru s-ar putea să vă surprindă atunci când vine vorba de optimizări și accelerarea codul, cred că nu trebuie să faceți verificări la getters și setteri, dar în codul în care sunteți actualizarea fișierelor sau bazei de date. Am greșit?

0
adăugat editat

8 răspunsuri

Ei bine, unul dintre argumentele pentru care clasele de obicei conțin membri privați cu getters / setters public este exact pentru că pot verifica datele.

Dacă aveți un număr mai mare decât cel care poate fi între 1 și 100, aș pune cu siguranță ceva în setter care validează acest lucru și apoi poate arunca o excepție care este prinsă de cod. Motivul este simplu: dacă nu o faci în setter, trebuie să ții minte faptul că o limitare de la 1 la 100 de fiecare dată când o seti, ceea ce duce la cod duplicat sau când îl uiți, duce la o stare nevalidă.

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

"Ar trebui să uităm de eficiența redusă, să zicem în jur de 97% din timp: optimizarea prematură este rădăcina tuturor răului".

0
adăugat

@ Terrapin, re:

Dacă tot ce ai este o grămadă de [simplu   public set / get] proprietăți ... ei   ar putea fi și câmpuri

Proprietățile au alte avantaje față de câmpuri. Sunt un contract mai explicit, sunt serializate, pot fi depanate mai târziu, sunt un loc frumos pentru extindere prin moștenire. Sintaxa clunkieră este o complexitate accidentală - de exemplu, .net 3.5 depășește acest lucru.

O practică comună (și defectuoasă) este de a începe cu câmpuri publice și de a le transforma în proprietăți mai târziu, pe o bază "după cum este necesar". Acest lucru vă rupe contractul cu oricine consumă clasa, deci este mai bine să începeți cu proprietățile.

0
adăugat

Validarea ar trebui să fie capturată separat de getters sau setters într-o metodă de validare. În acest fel, dacă validarea trebuie reutilizată pe mai multe componente, este disponibilă.

Când se cheamă setterul, un astfel de serviciu de validare ar trebui utilizat pentru a dezinstala intrarea în obiect. Astfel, știi că toate informațiile stocate într-un obiect sunt valabile în orice moment.

Nu aveți nevoie de nici un fel de validare pentru getter, deoarece informațiile despre obiect sunt deja de încredere că sunt valabile.

Nu salvați validarea până la actualizarea bazei de date! Este mai bine ca să nu reușească rapid .

0
adăugat
Ai putea elabora? Spui că, de exemplu, verificați <5 &&> 0 într-o metodă de validare separată? Atunci, ce anume fac cei care fac și cei care se ocupă de asta, ceea ce face un câmp obișnuit?
adăugat autor Boris Callens

Din perspectiva faptului că ai cel mai respectabil cod, cred că ar trebui să faci cât mai multă validare posibilă în setterul unei proprietăți. În acest fel, nu veți fi în cache sau nu vă veți ocupa în alt fel de date nevalide.

La urma urmei, acesta este scopul proprietăților. Dacă tot ce ai este o grămadă de proprietăți ca ...

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

... ar putea fi câmpuri

0
adăugat

Depinde.

În general, codul ar trebui să nu reușească rapid. Dacă valoarea poate fi setată de mai multe puncte din cod și validată numai după ce a fost recuperată valoarea, bug-ul pare să fie în codul care face actualizarea. Dacă setterii validă intrarea, știți ce cod încearcă să setați valori nevalide.

0
adăugat

Încerc să nu las niciodată obiectele mele să intre într-o stare nevalidă, așadar setteri definitiv ar avea validare, precum și orice metode care schimbă starea. În acest fel, nu trebuie să-mi fac griji că obiectul cu care mă confrunt este nevalid. Dacă vă păstrați metodele ca limite de validare, atunci nu trebuie să vă faceți griji cu privire la cadrele de validare și apelurile metodelor IsValid () stropite peste tot.

0
adăugat

Îmi place să pun în aplicare IDataErrorInfo și să pun logica de validare în Eroare și în această proprietate [columnName]. În acest fel, dacă doriți să verificați programatic dacă există o eroare, puteți să testați pur și simplu oricare dintre aceste proprietăți în cod sau puteți să transferați validarea în legarea datelor în Formulare Web, Windows Forms sau WPF.

Proprietatea de legare "ValidatesOnDataError" a WPF face acest lucru foarte ușor.

0
adăugat

S-ar putea să doriți să verificați Designed de Domeniu , de Eric Evans. DDD are această noțiune de specificație:

... predicat explicit ca VALUE   OBIECTE pentru scopuri specializate. A   SPECIFICAȚIA este un predicat care   determină dacă un obiect face sau nu   nu îndeplinesc anumite criterii.

Cred că eșecul rapid este un lucru, celălalt ar trebui să păstreze logica pentru validare. Domeniul este locul potrivit pentru păstrarea logicii și cred că un obiect de specificație sau o metodă validată pe obiectele domeniului dvs. ar fi un loc bun.

0
adăugat