Ar trebui să furnizez metode accessor / Getter Setters pentru componente publice / protejate pe un formular?

Dacă am formula .Net cu o componentă / obiect, cum ar fi o casetă de text pe care trebuie să o accesez de la un părinte sau altă formă, evident că trebuie să "actualizăm" modificatorul la această componentă la o variabilă de nivel intern sau public.

Acum, dacă aș fi furnizat o variabilă publică de tip int sau string etc. în clasa mea de formular, nu m-aș gândi de două ori în legătură cu utilizarea Getters și (poate) Setters în jurul acestui lucru, chiar dacă nu au făcut altceva decât să furnizeze direct accesul la variabila.

Cu toate acestea, proiectantul VS nu pare să implementeze astfel de Getters / Setteri pentru acele obiecte publice care sunt componente pe un formular (și, prin urmare, nu respectă practica de programare bună).

Deci, întrebarea este; Pentru a face "lucrurile potrivite" ar trebui să înfășoară asemenea componente sau obiecte designer VS într-un Getter și / sau un setter?

0
fr hi bn

4 răspunsuri

Mereu fac asta, și dacă sunteți în urma unui proiect MVP care creează getter / setters pentru vizualizarea dvs. componentele ar fi o cerință de proiectare.

Nu înțeleg ce vrei să spui prin "nu respectă bunele practici de programare". Microsoft încalcă mult bunele practici de programare pentru a face mai ușor crearea de lucruri pe Visual Studio (pentru dezvoltarea rapidă a aplicațiilor) și nu văd lipsa de getters / setters pentru controale ca dovadă a încălcând astfel de bune practici.

0
adăugat

Motivul pentru care nu am implementat Getters și Setters pentru componente pe un formular pe care cred că nu le-ar fi "Thread Safe". Obiectele nete se presupune a fi modificate numai de firul de formular care le-a creat. Dacă puneți getter și setters este posibil să o deschideți pentru orice fir. În schimb, presupuneți să implementați un sistem delegat în care modificările aduse acestor obiecte sunt delegate la firul care le-a creat și au fugit acolo.

0
adăugat

Acesta este un exemplu clasic de încapsulare în proiectarea orientată pe obiecte.

Un formular este un obiect a cărui responsabilitate este de a prezenta utilizatorului un utilizator și de a accepta o intrare. Interfața dintre obiectul Form și alte zone ale codului ar trebui să fie o interfață orientată spre date, nu o interfață care să expună detaliile de implementare interioară ale Formularului. Lucrările interioare ale Formularului (adică controalele) ar trebui să rămână ascunse de orice cod consumator.

O soluție matură ar presupune probabil următoarele puncte de proiectare:

  • Metodele sau proprietățile publice sunt comportamente (afișați, ascundeți, poziționați) sau orientați spre date (setați date, obțineți date, actualizați date).
  • Toate modulele de gestionare a evenimentelor implementate de Formular sunt împachetate în codul de delegare a firului corespunzător pentru a aplica regulile de executare a fișierelor.
  • Elementele de control se vor lega de datele structurii de date (dacă este cazul) pentru a reduce codul.

Și asta nici nu menționează lucruri de meta-dezvoltare cum ar fi teste unitare.

0
adăugat

" Cu toate acestea, designerul VS nu pare să implementeze astfel de Getters / Setteri pentru acele obiecte publice care sunt componente pe un formular (și, prin urmare, nu respectă bunele practici de programare). "

Dacă vă referiți la controalele pe care le glisați și plasați pe formular, acestea sunt marcate ca membri de instanță privată și sunt adăugați la colecția de controale a formularului. De ce ar fi altfel? Un formular ar putea avea patruzeci sau cincizeci de controale, ar fi oarecum inutil și greu să furnizeze un getter / setter pentru fiecare control al formularului. Designerul vă lasă la dispoziție accesul delegat la controale specifice prin intermediul getter / setters public.

Designerul are dreptate aici.

0
adăugat