Właściwości automatyczne C # 3.0 - przydatne czy nie? [Zamknięte]

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?

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.

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:

public string PropertyName { get; private set; }

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 readonlywłaściwości - tj. Niezmienne właściwości, których nie można zmienić poza konstruktorem:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

W czasie kompilacji stanie się to:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

W niezmiennych klasach z wieloma członkami pozwala to zaoszczędzić wiele nadmiarowego kodu.

Trzy poważne wady używania pól zamiast właściwości to:

1. Nie możesz powiązać danych z polem, podczas gdy możesz z właściwością
2. Jeśli zaczniesz od pola, nie możesz później (łatwo) zmienić go na właściwość
3. Istnieje kilka atrybutów, które możesz dodać do właściwości, których nie możesz dodać do pola

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.

Bjarne Stroustrup, twórca C ++:

Szczególnie nie lubię zajęć z wieloma funkcjami get i set. To często wskazuje, że w ogóle nie powinna to być klasa. To tylko struktura danych. A jeśli naprawdę jest to struktura danych, zrób z niej strukturę danych.

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ć.

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ć:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(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 setautoperty.

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.

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.

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:

public string Name = "DefaultName";

Musisz przenieść wartości domyślne do swoich konstruktorów z właściwościami. żmudne :-(

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:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

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.

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.

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ą.

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

• potrzebują dostępu do pola spoza jego zespołu, lub
• trzeba dołączyć logikę do metody pobierającej / ustawiającej

Zrób to:

1. zmienić nazwę pola
2. uczyń to prywatnym
3. dodać właściwość publiczną

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 .

Używam CodeRush, jest szybszy niż właściwości automatyczne.

Aby to zrobić:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Wymaga łącznie ośmiu naciśnięć klawiszy.

W przypadku fragmentów kodu właściwość automatyczna o tej samej nazwie oznaczałaby łącznie siedem naciśnięć klawiszy;)

@Domenic: Nie rozumiem ... czy nie możesz tego zrobić z właściwościami automatycznymi ?:

public string Title { get; }

lub

public string Title { get; private set; }

Czy to jest to, o czym mówisz?

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.