To ja się jeszcze dopiszę :)
(jeszcze taki mały OT przed postem - za chwilę pewnie wpadnie tu quetz który jest wielkim przeciwnikiem propetry {get;set;} i wyprowadzi mnie w brutalny sposób z błędu posiadania innej opinii (żartuję, oczywiście) ;). Tak czy inaczej... )
Na pierwszy rzut oka
int Count;
i
int Count {get; set;}
wyglądają podobnie. Na drugi zresztą też, bo odwoływanie do obydwóch jest takie same, czyli
int i = Count;
Count = i;
Tak naprawdę jednak property (czyli te gettery i settery) mają za zadanie symulować konstrukcje znane np. z C++
private:
int count;
public:
int getCount() { return count; }
void setCount(int value) { count = value; }
Ok, wracamy do C#. I rzeczywiście - na poziomie kodu "maszynowego" (czyli w przypadku C# oczywiście kodu pośredniego) zwykła zmienna zostanie zapisana po prostu (oczywiście to taka przenośnia, bo nie zamierzam ani siebie ani kogokolwiek katować IL-em ;) )
int Count;
co innego jeśli użyjemy właściwości. zapis int Count {get; set;} da nam w wyniku skądinąd znajomą konstrukcję... (edit: literówki)
private int Count; // ?
public int get_Count();
public int set_Count(int value);
(ten pytajnik to dlatego że ta zmienna musi być, ale nie mam pojęcia gdzie).
I w rzeczywistości odwołanie się do zmiennej również jest intuicyjne - czyli zmienna Count = 10; da nam to samo w kodzie wynikowym, gdz tymczasem i = property Count; da w wyniku i = get_Count(); Nie musisz mi wierzyć na słowo, dodaj do dowolnego swojego kodu deklarację funkcji z przedrostkiem get_ tak żeby kolidowała z nazwą właściwości a otrzymasz błąd kompilacji (Type (typ)' already reserves a member called 'get_(nazwa property)' with the same parameter types)
Jak wiadomo właściwości (czyli jakiekolwiek reagowanie na zmianę / pobranie zmiennej) są jednak czasami potrzebne. W niewielkim projekcie zmienienie zmiennej w właściwość nie powinno być trudne (po prostu wystarczy dopisać {get;set;}) - ale w sporym projekcie może być gorzej, jeśli np. zmienna w jednej klasie zostanie zmieniona we właściwość to wszystkie pozostałe biblioteki korzystające z tej klasy będą musiały być ponownie skompilowane (bo nie znajdą zmiennej nazwanej - zostawmy już to hipotetyczne - Count, a nic ich nie będzie obchodzić metoda get_Count(). ).
Dlatego właśnie dobrym zwyczajem jest też izolowanie pól klasy od świata zewnętrznego.
Ok, kończę już bo za chwilę długość tego posta zacznie dochodzić do średniej bświerczynskiego.
Mam nadzieję że nie napisałem nigdzie jakichś bzdur (marzenia), pozdrawiam...