Pola publiczne a właściwości automatyczne

Często mówi się nam, że powinniśmy chronić enkapsulację, tworząc metody getter i setter (właściwości w C#) dla pól klas, zamiast wystawiać te pola na zewnątrz.

Ale jest wiele razy, gdy pole jest po prostu tam, aby trzymać wartość i nie wymaga żadnych obliczeń, aby uzyskać lub ustawić. Dla nich wszyscy wykonalibyśmy ten numer:

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}
[[3]}cóż, mam wyznanie, nie mogłem znieść napisania tego wszystkiego (naprawdę, to nie musiało tego pisać, to musiało patrzeć na to), więc zbuntowałem się i użyłem publicznych pól.

Potem pojawia się C # 3.0 i widzę, że dodali właściwości automatyczne:

public class Book
{
    public string Title {get; set;} 
}
Co jest bardziej uporządkowane i jestem za to wdzięczny, ale naprawdę, czym się różni od tworzenia publicznego pola?
public class Book
{
    public string Title;
}
Author: Adi Lester, 2009-07-25

10 answers

W związanym z pytaniem miałem jakiś czas temu, był link do wpisu na blogu Jeffa, wyjaśniający pewne różnice.

Właściwości a zmienne publiczne

  • odbicie działa inaczej na zmiennych i właściwościach, więc jeśli polegasz na odbiciu, łatwiej jest używać wszystkich właściwości.
  • nie można porównywać danych ze zmienną.
  • Zmiana zmiennej na właściwość jest zmianą łamającą. Na przykład:

    TryGetTitle(out book.Title); // requires a variable
    
 148
Author: Michael Stum,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:26:22

Ignorując problemy z API, najbardziej wartościową rzeczą w używaniu właściwości jest debugowanie.

Debugger CLR nie obsługuje punktów przerwania danych (Większość debugerów natywnych tak robi). Dlatego nie jest możliwe ustawienie punktu przerwania dla odczytu lub zapisu określonego pola na klasie. Jest to bardzo ograniczone w niektórych scenariuszach debugowania.

Ponieważ właściwości są zaimplementowane jako bardzo cienkie metody, można ustawić punkty przerwania przy odczycie i zapisie ich wartości. To daje im dużą nogę nad polami.

 71
Author: JaredPar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-07-25 01:22:58

Zmiana z pola na właściwość przerywa umowę (np. wymaga przekompilowania całego kodu odniesienia). Więc kiedy masz punkt interakcji z innymi klasami-dowolnym publicznym (i ogólnie chronionym) członkiem, chcesz zaplanować przyszły rozwój. Rób to zawsze używając właściwości.

To nic, aby to auto-własność dzisiaj, a 3 miesiące w dół linii uświadomić sobie, że chcesz, aby to leniwy załadowany, i umieścić null czek w getter. Jeśli użyłeś pola, jest to przekompiluj zmiany w najlepszym razie i niemożliwe w najgorszym, w zależności od tego, kto i co jeszcze zależy od Twoich zestawów.

 56
Author: Rex M,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-07-25 01:07:24

Tylko dlatego, że nikt o tym nie wspomniał: nie można definiować pól na interfejsach. Tak więc, jeśli musisz zaimplementować konkretny interfejs, który definiuje właściwości, auto-właściwości czasami są naprawdę fajną funkcją.

 55
Author: MartinStettner,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-04 01:53:38

Ogromna różnica, która jest często pomijana i nie jest wymieniona w żadnej innej odpowiedzi: overriding . Możesz zadeklarować właściwości wirtualne i nadpisać je, podczas gdy nie możesz zrobić tego samego dla publicznych pól członkowskich.

 42
Author: Zaid Masud,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-25 11:49:05

Kolejną zaletą automatycznie zaimplementowanych właściwości nad polami publicznymi jest to, że można ustawić accessory jako prywatne lub chronione, zapewniając klasę obiektów, w których została zdefiniowana, lepszą kontrolę niż w przypadku pól publicznych.

 10
Author: Arnaldo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-11 18:18:02

Chodzi o wersjonowanie i stabilność API. Nie ma różnicy, w wersji 1 - ale później, jeśli zdecydujesz, że chcesz uczynić tę właściwość z pewnego rodzaju sprawdzaniem błędów w wersji 2, nie musisz zmieniać swojego API - żadnych zmian kodu, gdziekolwiek, poza definicją właściwości.

 7
Author: Reed Copsey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-07-25 01:09:21

Nie ma nic złego w tworzeniu pola public. Pamiętaj jednak, że tworzenie getter/setter z polami private nie jest hermetyzacją. IMO, jeśli nie dbasz o inne cechy Property, równie dobrze możesz to zrobić public.

 7
Author: fastcodejava,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-04 02:20:13

Jeśli później zdecydujesz się sprawdzić, czy tytuł jest unikalny, porównując do kolekcji lub bazy danych, możesz to zrobić we właściwości bez zmiany kodu, który od niej zależy.

Jeśli wybierzesz tylko atrybut publiczny, będziesz miał mniejszą elastyczność.

Dodatkowa elastyczność bez zerwania umowy jest dla mnie najważniejsza w korzystaniu z właściwości i dopóki nie potrzebuję elastyczności, automatyczne generowanie ma największy sens.

 0
Author: James Black,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-07-25 01:45:12

Jedną z rzeczy, które uważam za bardzo przydatne, jak również wszystkie powody kodu i testowania, jest to, że jeśli jest to właściwość vs pole, to IDE Visual Studio pokazuje odniesienia do właściwości, ale nie pola.

 0
Author: TrtlBoy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-20 03:19:55