Wady korzystania z właściwości tylko bez odpowiednich pól w .NET?

Question

Mam klasy, które mają właściwości automatyczne tylko takie jak public customerName {get; zestaw;}. Są publiczne, ponieważ są dostępne poza klasą. Dostęp do nich można uzyskać również na zajęciach. Oferują dobrą enkapsulację i lepsze debugowanie. Mogę umieścić punkt przerwania na jednym, jeśli chcę wiedzieć, kto ma do niego dostęp i kiedy.

Moje pytanie brzmi: jakie są wady korzystania z właściwości tylko bez odpowiednich pól? Mogę sprawić, żeby seter lub zdobywca był prywatny, wewnętrzny ... itp. Co oznacza, że ​​mam również elastyczność w zakresie określania zakresu w razie potrzeby.

Answer 1

serializacji z BinaryFormatter - trzeba duże problemy, jeśli trzeba zmienić swoją nieruchomość do „zwykłej” własności później, na przykład, aby dodać niektóre walidacji/WKKW/etc - sinc BinaryFormatter używa nazwy pól. I nie można tego duplikować, ponieważ nazwa pola generowanego przez kompilator nie może być napisana jako legalny C#.

Co jest dobrym powodem, aby zamiast tego spojrzeć na serializator oparty na umowie. Aby uzyskać więcej informacji, patrz this blog entry.

Answer 2

Nie ma wad w przypadku prostych właściwości. Kompilator tworzy dla ciebie pole wsparcia. Ten blog entry wyjaśnia, w jaki sposób kompilator traktuje automatycznie zaimplementowane właściwości.

Answer 3

Chodzi o to, że to odpowiadające pole. Po prostu tego nie widać, ponieważ kompilator tworzy go dla ciebie. Właściwości automatyczne są po prostu syntaktycznym cukrem lub skrótowym sposobem tworzenia pola.

Answer 4

Nie można utworzyć właściwości prawdziwie czytającej tylko, ponieważ trzeba zdefiniować zarówno setter, jak i getter. Możesz użyć prywatnego ustawiacza, aby uzyskać właściwość pseudo-tylko do odczytu z zewnątrz.

W przeciwnym razie, jak wspomniano powyżej, nie ma żadnych innych wad.

Answer 5

Bez większych rzeczy. Tylko przypadki krawędzi, takie jak miejsce, gdzie musisz przekazać właściwość do metody, w której parametr jest przekazywany przez odniesienie (ref lub out), co nie jest możliwe w przypadku właściwości (ponieważ wewnętrznie są to po prostu metody get_Property/set_Property implementowane przez kompilator , a nie specjalne pola) i potrzebujesz do tego jawnego prywatnego pola wsparcia.

EDYCJA: Och, i delegowanie właściwości "no readonly", co jest dość powszechne.

Answer 6

Jeśli nie trzeba wykonywać żadnych szczególnych logikę w Pobierz i/lub ustaw dostępowych, nie ma wadę ...

Answer 7

mówię, że są złe z punktu widzenia czytelności kodu. Składnia cukru jest dobra do pisania kodu, ale okropna do czytania kodu. Jako deweloperzy, kod, który zostawiamy w tyle, zostanie ostatecznie odziedziczony przez jakiegoś biednego programistę, który będzie musiał zrozumieć, co zrobiliśmy i co się dzieje w kodzie. Naprawdę jestem przeciwny zmianie języka, aby po prostu zapisać naciśnięcia klawiszy, gdy istnieje ustalona składnia dla tych samych konstrukcji.

Answer 8

Naprawdę nie jest to wadą, ale należy pamiętać o domyślnych wartościach właściwości automatycznych. Z "klasycznymi" właściwościami zawsze używaliśmy do inicjowania pól bazowych, np. w następujący sposób:

private bool _flag = true; 
public bool Flag 
{ 
    get { return _flag; } 
    set { _flag = value; } 
} 

Dzięki temu było oczywiste, jaka jest domyślna wartość właściwości.

Przy właściwościach automatycznych, musisz wiedzieć, jakie są wartości domyślne dla różnych typów (np. False dla bool). Jeśli nie chcesz właściwość mieć wartość domyślną trzeba zainicjować w konstruktorze:

class MyClass 
{ 
    public bool Flag { get; set; } 
    public MyClass() 
    { 
    Flag = true; 
    } 
} 

Oznacza to, ty trzeba zaimplementować konstruktor jeśli chcesz zainicjować swoje właściwości do nieprzestrzegania Domyślnie wartości lub jeśli właściwość jest typu odniesienia (klasa).

Ale tak jak napisałem, nie uważam tego za wady, po prostu coś, co trzeba wiedzieć.