2009-08-13 19 views
13

Ilekroć pojawia się pytanie o wiarygodność właściwości, widzę, że większość dyskusji odbywa się wokół funkcji/metod w stosunku do właściwości. Ale chciałbym również poznać przekonujące powód do korzystania z nieruchomości z towarzyszącym prywatnym polu vs dziedzinie publicznej bezpośrednio samego, okrywać najczęstszych get/set zachowań bez innej obróbki, to znaczy w ten sposóbWłaściwość (bez dodatkowego przetwarzania) a pole publiczne

public string CustomerName; 

vs

private string customerName; 
public string CustomerName 
{ 
get{return customerName;} 
set(string value){this.customerName=value;} 
} 
+5

Możesz także zrobić "public string CustomerName {get; set;}" – cyberconte

Odpowiedz

22

uzyskać źródło/kompatybilność binarną jeśli później trzeba dodać inne zachowania, można dostać się, aby dodać punkty przerwy, i to tylko filozoficznie czystsze (troska o zachowanie, a nie poprzez mechanizm przechowywania).

Należy pamiętać, że nie trzeba cały ostatniego bloku w C# 3:

public string CustomerName { get; set; } 

Zobacz my article on "Why Properties Matter" aby uzyskać więcej informacji.

+0

Jon.. Widzę twój punkt. Ale jakoś poczułem, że kod będzie czystszy w inny sposób, tj. Jeśli w klasie jest więcej pól (powiedzmy 30+), to liczba linii kodu będzie co najmniej czterokrotnie większa w przypadku właściwości. Teraz automatyczne właściwości w C# 3 i VB 10 sprawiają, że wszyscy jesteśmy szczęśliwi !!! – Raj

+7

Jeśli masz 30 pól w swojej klasie, powinieneś prawdopodobnie użyć więcej enkapsulacji na początek. –

+1

Tylko po to, aby potwierdzić, że rozumiem o enkapsulacji, grupując logiczne podzestawy dużych pól w jednej klasie na różne klasy/interfejsy i otrzymuję je poprzez dziedziczenie lub kompozycję. Czy to jest poprawne? Jeśli tak, to nadal zawierałoby dodatkowe obciążenie kodu podzielone na różne klasy, a nie na jedną klasę. Przepraszam, jeśli podsycam cię nonsensem. To wszystko z powodu mojej frustracji w utrzymywaniu tysięcy linii kodu (z dużą ilością właściwości bez dodatkowej logiki) napisanych przez kogoś innego. – Raj

3
  1. Można zastąpić albo przynajmniej stworzyć „nową” właściwość w klasie pochodnej

  2. W tym momencie ludzie oczekują właściwości narażone i pola, aby być ukryte. Jeśli ktoś ma zamiar zastanowić się nad twoją klasą (staje się coraz bardziej popularny dzięki narzędziom takim jak Castle Windsor, NHibernate), istnieje wielka różnica, prawdopodobnie nie będą sprawdzać odkrytych pól.

1

Możesz również zapewnić podstawową weryfikację właściwości. Na przykład, aby zapobiec ustawiając właściwość nieprawidłowym stanie jak ujemnej wartości dla wysokości:

private int height; 
public int Height 
{ 
    get{ return height; } 
    set 
    { 
    if (value > 0) 
    { 
     height = value; 
    } 
    } 
} 
+1

Zgadzam się, że wszelkie dodatkowe przetwarzanie, takie jak sprawdzanie poprawności, sprawia, że ​​oczywiste jest, aby używać właściwości. Właśnie dlatego wyraźnie wspomniałem o braku takiego dodatkowego przetwarzania. – Raj

2

Jest to głównie błąd w Javie. W wielu innych językach (Python, Delphi, Groovy) kompilator wygeneruje moduły pobierające i ustawiające dla ciebie , chyba że podasz kod w postaci.

Oznacza to, że możesz użyć pola "publicznego" w Groovy, a kompilator wygeneruje dyskretnie i wywoła setter/setter. Jeśli potrzebujesz dodatkowej magii przy zmianie pola, możesz wprowadzić specjalistę ustawiającego i wszystko będzie działać.

To jedna z tych rzeczy, w których rzeczywistość koliduje z projektem. Projektanci Javy nie chcieli, aby kompilator robił coś, czego nie widać. To, co wydawało się dobrym pomysłem wiele lat temu, nie wypadło zbyt dobrze.

+0

Uwaga: W pytaniu początkowo brakowało znacznika języka, więc ta odpowiedź zakłada, że ​​kod w pytaniu to Java; Tag [tag: C#] został dodany później. – mklement0

2

Zauważam jedno pomocne użytkowanie nieruchomości. Jeśli zamierzasz powiązać kolekcję obiektu z formantem DataGrid lub DataGridView lub inną formantem wiążącym, jedynymi rozpoznawalnymi nazwami podlegającymi ocenie są pola Właściwość, a nie pola publiczne.

Powiązane problemy