Uwaga: to zostało opublikowane, gdy zaczynałem C #. Mając wiedzę z 2014 roku, mogę naprawdę powiedzieć, że właściwości automatyczne należą do najlepszych rzeczy, jakie kiedykolwiek przydarzyły się językowi C #.
Jestem używany do tworzenia moich właściwości w C # przy użyciu pola prywatnego i publicznego:
private string title;
public string Title
{
get { return title; }
set { title = value; }
}
Teraz, dzięki .NET 3.0, mamy właściwości automatyczne:
public string Title { get; set; }
Wiem, że jest to bardziej pytanie filozoficzne / subiektywne, ale czy jest jakiś powód, aby używać tych właściwości automatycznych poza zapisaniem pięciu wierszy kodu dla każdego pola? Moim osobistym problemem jest to, że te właściwości ukrywają przede mną rzeczy, a ja nie jestem wielkim fanem czarnej magii.
W rzeczywistości ukryte pole prywatne nawet nie pojawia się w debugerze, co jest w porządku, biorąc pod uwagę fakt, że funkcje get / set nic nie robią. Ale kiedy chcę faktycznie zaimplementować jakąś logikę getter / setter, i tak muszę użyć pary prywatna / publiczna.
Widzę korzyść, że zapisuję dużo kodu (jeden na sześć wierszy) bez utraty możliwości późniejszej zmiany logiki pobierającej / ustawiającej, ale z drugiej strony mogę już to zrobić, po prostu deklarując pole publiczne „Public string Title” bez potrzeba {get; zestaw; }, co pozwala na zapisanie większej ilości kodu.
Więc czego tu brakuje? Dlaczego ktokolwiek miałby chcieć używać właściwości automatycznych?
źródło
Odpowiedzi:
Używamy ich cały czas w Stack Overflow.
Możesz być także zainteresowany omówieniem właściwości i zmiennych publicznych . IMHO to naprawdę jest to, na co jest to reakcja, i do tego celu jest świetny.
źródło
Tak, po prostu zapisuje kod. Znacznie łatwiej jest je odczytać, gdy jest ich dużo. Są szybsze w pisaniu i łatwiejsze w utrzymaniu. Zapisywanie kodu jest zawsze dobrym celem.
Możesz ustawić różne zakresy:
Tak więc właściwość można zmienić tylko wewnątrz klasy. Nie jest to niezmienne, ponieważ nadal możesz uzyskać dostęp do prywatnego ustawiacza poprzez refleksję.
Od C # 6 można również tworzyć prawdziwe
readonly
właściwości - tj. Niezmienne właściwości, których nie można zmienić poza konstruktorem:W czasie kompilacji stanie się to:
W niezmiennych klasach z wieloma członkami pozwala to zaoszczędzić wiele nadmiarowego kodu.
źródło
Trzy poważne wady używania pól zamiast właściwości to:
źródło
Osobiście uwielbiam nieruchomości samochodowe. Co jest złego w zapisywaniu linii kodu? Jeśli chcesz robić coś w getterach lub setterach, nie ma problemu z konwersją ich później do normalnych właściwości.
Jak powiedziałeś, możesz użyć pól, a jeśli chcesz później dodać do nich logikę, przekonwertuj je na właściwości. Może to jednak stwarzać problemy z jakimkolwiek wykorzystaniem refleksji (i być może gdzie indziej?).
Właściwości pozwalają także ustawić różne poziomy dostępu dla metody pobierającej i ustawiającej, których nie można zrobić z polem.
Myślę, że to to samo, co słowo kluczowe var. Kwestia osobistych preferencji.
źródło
Bjarne Stroustrup, twórca C ++:
I wiesz co? On ma rację. Jak często po prostu zawijasz pola prywatne w get and set, bez robienia czegokolwiek w get / set, po prostu dlatego, że jest to czynność „obiektowa”. To jest rozwiązanie problemu firmy Microsoft; są to w zasadzie pola publiczne, do których można się przypisać.
źródło
Wydaje się, że nikt nie wspomniał o tym, że właściwości automatyczne nie są niestety przydatne w przypadku niezmiennych obiektów (zwykle niezmiennych struktur). Ponieważ w tym celu naprawdę powinieneś zrobić:
(gdzie pole jest inicjowane w konstruktorze za pośrednictwem przekazanego parametru, a następnie jest tylko do odczytu).
Więc ma to zalety w porównaniu z prostym
get
/private set
autoperty.źródło
public string Title { get; private set; }
spowodowałoby to dokładnie tego samego? Oczywiście możesz to zmienić z poziomu klasy, ale jeśli to zrobisz, będziesz mieć inne problemy ...: ppublic string Title { get; private readonly set; }
Zawsze tworzę właściwości zamiast pól publicznych, ponieważ możesz używać właściwości w definicji interfejsu, nie możesz używać pól publicznych w definicji interfejsu.
źródło
Właściwości automatyczne są tak samo czarną magią, jak wszystko inne w C #. Kiedy pomyślisz o tym w kategoriach kompilacji do IL, a nie rozszerzania go do normalnej właściwości C #, to jest o wiele mniej czarnej magii niż wiele innych konstrukcji językowych.
źródło
Cały czas używam właściwości automatycznych. Przed C # 3 nie mogłem zawracać sobie głowy pisaniem i po prostu użyłem zmiennych publicznych.
Jedyne, czego mi brakuje, to możliwość zrobienia tego:
Musisz przenieść wartości domyślne do swoich konstruktorów z właściwościami. żmudne :-(
źródło
public string Name { get; set; } = "DefaultName";
blogs.msdn.com/b/csharpfaq/archive/2014/11/20/…Myślę, że każda konstrukcja, która jest intuicyjna ORAZ redukuje linie kodu, jest dużym plusem.
To właśnie te cechy sprawiają, że języki takie jak Ruby są tak potężne (to i dynamiczne funkcje, które również pomagają zredukować nadmiar kodu).
Ruby miał to przez cały czas jako:
źródło
Jedyny problem jaki mam z nimi to to, że nie idą wystarczająco daleko. W tej samej wersji kompilatora, która dodała właściwości automatyczne, dodano metody częściowe. Dlaczego nie połączyli tych dwóch razem, jest poza mną. Prosta „częściowa zmiana na <PropertyName>” sprawiłaby, że te rzeczy byłyby naprawdę przydatne.
źródło
To proste, krótkie i jeśli chcesz stworzyć prawdziwą implementację wewnątrz ciała właściwości gdzieś w dół, nie zepsuje to zewnętrznego interfejsu twojego typu.
Tak proste jak to.
źródło
Należy tu zauważyć, że według mojego zrozumienia jest to po prostu cukier syntaktyczny na końcu języka C # 3.0, co oznacza, że IL generowany przez kompilator jest taki sam. Zgadzam się co do unikania czarnej magii, ale mimo wszystko mniej wierszy na to samo jest zazwyczaj dobrą rzeczą.
źródło
Moim zdaniem należy zawsze używać właściwości automatycznych zamiast pól publicznych. To powiedziawszy, oto kompromis:
Zacznij od pola wewnętrznego przy użyciu konwencji nazewnictwa, której użyjesz dla właściwości. Kiedy pierwszy raz
Zrób to:
Twój kod klienta nie będzie musiał się zmieniać.
Jednak pewnego dnia Twój system będzie się rozrastał i rozłożysz go na osobne zestawy i wiele rozwiązań. Kiedy tak się stanie, wszystkie ujawnione pola wrócą, aby cię prześladować, ponieważ, jak wspomniał Jeff, zmiana pola publicznego na właściwość publiczną jest przełomową zmianą interfejsu API .
źródło
Używam CodeRush, jest szybszy niż właściwości automatyczne.
Aby to zrobić:
Wymaga łącznie ośmiu naciśnięć klawiszy.
źródło
W przypadku fragmentów kodu właściwość automatyczna o tej samej nazwie oznaczałaby łącznie siedem naciśnięć klawiszy;)
źródło
@Domenic: Nie rozumiem ... czy nie możesz tego zrobić z właściwościami automatycznymi ?:
lub
Czy to jest to, o czym mówisz?
źródło
Moim największym problemem związanym z właściwościami automatycznymi jest to, że zostały zaprojektowane, aby zaoszczędzić czas, ale często muszę później rozszerzyć je do pełnowymiarowych właściwości.
To, czego brakuje VS2008, to refaktoryzacja właściwości automatycznej eksplodującej.
Fakt, że mamy enkapsulowany refaktor pola sprawia, że mój sposób pracy jest szybszy, aby po prostu używać pól publicznych.
źródło