C # 3.0 auto-proprietăți - utile sau nu?

Notă: A fost postat când am început să încep C #. Cu cunoștințele din 2014, pot spune cu adevărat că proprietățile auto sunt printre cele mai bune lucruri care s-au întâmplat vreodată în limba C #.

Sunt obișnuit să-mi creez proprietățile în C# folosind un câmp privat și public:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Acum, cu .NET 3.0, avem auto-proprietăți:

public string Title { get; set; }

Știu că aceasta este mai mult o întrebare filosofică/subiectivă, dar există vreun motiv pentru a utiliza aceste proprietăți auto, cu excepția salvării a cinci rânduri de cod pentru fiecare domeniu? Gripa mea personală este că acele proprietăți ascund lucruri de la mine și nu sunt un mare fan al magiei negre.

De fapt, câmpul privat ascuns nu apare chiar în aplicația de depanare, ceea ce este OK având în vedere faptul că funcțiile get/set nu fac nimic. Dar când vreau să implementez o logică getter/setter, trebuie să folosesc oricum perechea privată/publică.

Eu văd avantajul că salvez o mulțime de cod (unul vs șase linii) fără a pierde abilitatea de a schimba logica getter/setter mai târziu, dar din nou pot deja să fac asta prin simpla declarare a câmpului public "Public Title string" fără nevoia {get; a stabilit; } bloc, astfel salvând chiar mai mult cod.

Deci, ce-mi lipsește aici? De ce ar vrea cineva să utilizeze proprietățile auto?

0
fr hi bn
"Gripa mea personală este că acele proprietăți ascund lucruri de la mine și nu sunt un mare fan al magiei negre". Nu-i asa? Sunteți conștient de faptul că compilatorul ascunde o tonă de la tine tot timpul, nu? Dacă nu scrieți un ansamblu (sau, mai exact, codurile 1 și 0 pentru codul dvs.), tot ce scrieți ascunde lucruri de la dvs.
adăugat autor Charles Boyung, sursa

2 răspunsuri

Îmi plac personal proprietățile auto. Ce este în neregulă cu salvarea liniilor de cod? Dacă doriți să faceți lucruri în getters sau setters, nu există nici o problemă pentru a le converti mai târziu la proprietăți normale.

După cum ați spus că puteți folosi câmpuri și dacă doriți să le adăugați logică, le-ați transformat în proprietăți. Dar acest lucru ar putea prezenta probleme cu orice folosire a reflecției (și, eventual, în altă parte?).

De asemenea, proprietățile vă permit să setați diferite nivele de acces pentru getter și setter pe care nu le puteți face cu un câmp.

Cred că este același cu cuvântul cheie var. O chestiune de preferință personală.

0
adăugat

Cele trei dezavantaje majore de a utiliza câmpuri în loc de proprietăți sunt:

  1. Nu poți să creezi un baze de date pe un câmp în timp ce poți la o proprietate
  2. Dacă începeți să utilizați un câmp, nu îl puteți modifica ulterior (ușor) la o proprietate
  3. Există unele atribute pe care le puteți adăuga la o proprietate pe care nu o puteți adăuga la un câmp
0
adăugat
"Dacă începeți să utilizați un câmp, nu îl puteți schimba mai târziu (cu ușurință) la o proprietate", îmi pare rău dar de ce?
adăugat autor Homam, sursa
@Homam În principal, orice cod de consum care utilizează reflexia pe câmpurile dvs. ar sparge, deoarece ar trebui să treacă de la utilizarea FieldInfo la PropertyInfo.
adăugat autor WCWedin, sursa