Używać pól czy właściwości w przypadku tylko przypisania i zwrócenia wartości? Czyli nie używać nigdy pól? Enkapsulacja i te sprawy.
Inaczej czy pisać publiczne pola:
public string name
czy właściwości automatyczne:
public string Name{ get; set; }
A co z private?
Takie coś wydaje mi się bezsensu:
private string Name{ get; set; }
chyba po prostu pisać tak:
private string name
Własności często są wykorzystywane przez zewnętrzne komponenty poprzez refleksje. Sam musisz wiedzieć czy chcesz to wykorzystywać czy nie.
Aby zobaczyć przykładowąróżnice zobacz jak zachowa się DataGrid jeżeli zbindujesz do jego sourca kolekcje elementów jakiegoś własnego typu. Najpierw do typu dodaj Name z get,set a potem usuń get,set. Zobacz jak zachowa się grid.
Dodatkowo w get, set zawsze możesz zawrzeć dodatkową logikę. Na przykład cześć implementacji do INotifyPropertyChanged.
Jeśli ma być publiczne, to właściwości, jeśli prywatne to pole. Więcej info tutaj: Do czego służą akcesory w c#?
Takie coś wydaje mi się bezsensu:
private string Name{ get; set; }
Kwestia gustu. Takie cos daje ci mozliwosc dodania pozniej jakiegos kodu a to chcyba raczej jest na plus. Rowniez dzieki temu mozna to debugowac. Jest jeszcze kilka rzeczy z tym zwiazanych, ale mysle ze na poczatku nie ma sobie co zawracac tym glowy
mca64 napisał(a):
Kwestia gustu. Takie cos daje ci mozliwosc dodania pozniej jakiegos kodu a to chcyba raczej jest na plus. Rowniez dzieki temu mozna to debugowac. Jest jeszcze kilka rzeczy z tym zwiazanych, ale mysle ze na poczatku nie ma sobie co zawracac tym glowy
Jeśli zrobi pole, to też będzie mogła później dodać jakiś kod i debugować. Z prywatnego pola na pewno nic nie korzysta, więc refaktoryzacja tego nie zepsuje żadnych innych modułów ani aplikacji.
Prywatne właściwości mają sens w specyficznych sytuacjach, np. jeśli są wraperami na słowniki w rodzaju ViewState lub Session w ASP.NET, ale wówczas faktycznie zawierają w sobie jakąś logikę.