Jaka jest różnica między polem a właściwością?

Co w C # odróżnia pole od właściwości i kiedy należy użyć pola zamiast właściwości?

Właściwości ujawniają pola. Pola powinny (prawie zawsze) być prywatne dla klasy i dostępne za pośrednictwem właściwości get i set. Właściwości zapewniają poziom abstrakcji, który pozwala zmieniać pola, nie wpływając jednak na sposób, w jaki są dostępne dla rzeczy używanych przez twoją klasę.

public class MyClass
{
    // this is a field.  It is private to your class and stores the actual data.
    private string _myField;

    // this is a property. When accessed it uses the underlying field,
    // but only exposes the contract, which will not be affected by the underlying field
    public string MyProperty
    {
        get
        {
            return _myField;
        }
        set
        {
            _myField = value;
        }
    }

    // This is an AutoProperty (C# 3.0 and higher) - which is a shorthand syntax
    // used to generate a private field for you
    public int AnotherProperty{get;set;} 
}

@Kent zwraca uwagę, że właściwości nie są wymagane do enkapsulacji pól, mogą wykonać obliczenia na innych polach lub służyć innym celom.

@GSS wskazuje, że możesz także wykonywać inne operacje logiczne, takie jak sprawdzanie poprawności, gdy dostęp do właściwości jest kolejną przydatną funkcją.

Zorientowane obiektowo zasady programowania mówią, że wewnętrzne działanie klasy powinno być ukryte przed światem zewnętrznym. Jeśli ujawnisz pole, w gruncie rzeczy odsłonisz wewnętrzną implementację klasy. Dlatego zawijamy pola właściwościami (lub metodami w przypadku Javy), aby umożliwić nam zmianę implementacji bez rozbijania kodu w zależności od nas. Widząc, jak możemy umieścić logikę we właściwości, pozwala nam również wykonywać logikę sprawdzania poprawności itp., Jeśli jest to potrzebne. C # 3 ma prawdopodobnie mylące pojęcie właściwości automatycznych. To pozwala nam po prostu zdefiniować Właściwość, a kompilator C # 3 wygeneruje dla nas prywatne pole.

public class Person
{
   private string _name;

   public string Name
   {
      get
      {
         return _name;
      }
      set
      {
         _name = value;
      }
   }
   public int Age{get;set;} //AutoProperty generates private field for us
}

Ważną różnicą jest to, że interfejsy mogą mieć właściwości, ale nie pola. To, według mnie, podkreśla, że ​​właściwości powinny być używane do definiowania publicznego interfejsu klasy, podczas gdy pola mają być używane w prywatnych, wewnętrznych działaniach klasy. Z reguły rzadko tworzę pola publiczne i podobnie rzadko tworzę nieruchomości niepubliczne.

Podam kilka przykładów użycia właściwości, które mogą spowodować zmianę biegów:

• Leniwa inicjalizacja : Jeśli masz właściwość obiektu, który jest kosztowny w załadowaniu, ale nie jest dostępny tak często w normalnych uruchomieniach kodu, możesz opóźnić jego załadowanie za pośrednictwem tej właściwości. W ten sposób po prostu tam siedzi, ale za pierwszym razem, gdy inny moduł próbuje wywołać tę właściwość, sprawdza, czy pole leżące u jej podstaw jest puste - jeśli tak, idzie do przodu i ładuje je, nieznane modułowi wywołującemu. Może to znacznie przyspieszyć inicjalizację obiektu.
• Dirty Tracking: O czym właściwie dowiedziałem się z mojego własnego pytania na StackOverflow. Gdy mam wiele obiektów, których wartości mogły ulec zmianie podczas przebiegu, mogę użyć właściwości do śledzenia, czy trzeba je zapisać z powrotem w bazie danych, czy nie. Jeśli żadna właściwość obiektu nie ulegnie zmianie, flaga IsDirty nie zostanie wyzwolona, ​​a zatem funkcja zapisywania pominie ją przy podejmowaniu decyzji o tym, co należy wrócić do bazy danych.

Za pomocą właściwości można wywołać zdarzenie, gdy wartość właściwości zostanie zmieniona (inaczej. PropertyChangedEvent) lub przed zmianą wartości w celu obsługi anulowania.

Nie jest to możliwe w przypadku pól (bezpośredni dostęp do).

public class Person {
 private string _name;

 public event EventHandler NameChanging;     
 public event EventHandler NameChanged;

 public string Name{
  get
  {
     return _name;
  }
  set
  {
     OnNameChanging();
     _name = value;
     OnNameChanged();
  }
 }

 private void OnNameChanging(){       
     NameChanging?.Invoke(this,EventArgs.Empty);       
 }

 private void OnNameChanged(){
     NameChanged?.Invoke(this,EventArgs.Empty);
 }
}

Ponieważ wiele z nich wyjaśniło zalety i wady techniczne Propertiesoraz Field, nadszedł czas na przykłady w czasie rzeczywistym.

1. Właściwości pozwala ustawić poziom dostępu tylko do odczytu

Rozważ przypadek dataTable.Rows.Counti dataTable.Columns[i].Caption. Pochodzą z klasy DataTablei oba są dla nas publiczne. Różnica w poziomie dostępu do nich polega na tym, że nie możemy ustawić wartości, dataTable.Rows.Countale możemy czytać i pisać dataTable.Columns[i].Caption. Czy to możliwe Field? Nie!!! Można to zrobić Propertiestylko za pomocą .

public class DataTable
{
    public class Rows
    {       
       private string _count;        

       // This Count will be accessable to us but have used only "get" ie, readonly
       public int Count
       {
           get
           {
              return _count;
           }       
       }
    } 

    public class Columns
    {
        private string _caption;        

        // Used both "get" and "set" ie, readable and writable
        public string Caption
        {
           get
           {
              return _caption;
           }
           set
           {
              _caption = value;
           }
       }       
    } 
}

2. Właściwości w PropertyGrid

Być może pracowałeś Buttonw Visual Studio. Jego właściwości są pokazane w PropertyGridniczym Text, Nameitd. Kiedy przeciągnij i upuść przycisk, a kiedy klikamy właściwości, zostanie ona automatycznie znaleźć klasy Buttoni filtry Propertiesi pokazać, że w PropertyGrid(gdzie PropertyGridnie pokaże Fieldchociaż są publiczne).

public class Button
{
    private string _text;        
    private string _name;
    private string _someProperty;

    public string Text
    {
        get
        {
           return _text;
        }
        set
        {
           _text = value;
        }
   } 

   public string Name
   {
        get
        {
           return _name;
        }
        set
        {
           _name = value;
        }
   } 

   [Browsable(false)]
   public string SomeProperty
   {
        get
        {
           return _someProperty;
        }
        set
        {
           _someProperty= value;
        }
   } 

W PropertyGrid, właściwości Namei Textzostaną pokazane, ale nie SomeProperty. Dlaczego??? Ponieważ właściwości mogą akceptować atrybuty . Nie pokazuje się w przypadku, gdy [Browsable(false)]fałsz.

3. Potrafi wykonywać instrukcje w obrębie Właściwości

public class Rows
{       
    private string _count;        


    public int Count
    {
        get
        {
           return CalculateNoOfRows();
        }  
    } 

    public int CalculateNoOfRows()
    {
         // Calculation here and finally set the value to _count
         return _count;
    }
}

4. Tylko właściwości mogą być używane w Binding Source

Binding Source pomaga nam zmniejszyć liczbę wierszy kodu. Fieldsnie są akceptowane przez BindingSource. Powinniśmy do tego wykorzystać Properties.

5. Tryb debugowania

Rozważmy, że używamy Fielddo przechowywania wartości. W pewnym momencie musimy debugować i sprawdzić, gdzie wartość staje się pusta dla tego pola. Trudno będzie to zrobić, gdy liczba wierszy kodu jest większa niż 1000. W takich sytuacjach możemy użyć Propertyi ustawić tryb debugowania wewnątrz Property.

   public string Name
   {
        // Can set debug mode inside get or set
        get
        {
           return _name;
        }
        set
        {
           _name = value;
        }
   }

RÓŻNICE - ZASTOSOWANIA (kiedy i dlaczego)

Pole jest zmienną, która jest zadeklarowana bezpośrednio w klasie lub struktura. Klasa lub struktura może mieć pola instancji lub pola statyczne lub oba te elementy. Zasadniczo należy używać pól tylko dla zmiennych, które mają dostęp prywatny lub chroniony . Dane, które klasa wystawia na kod klienta, należy przekazywać metodami, właściwościami i indeksatorami. Korzystając z tych konstrukcji do pośredniego dostępu do pól wewnętrznych, można zabezpieczyć się przed nieprawidłowymi wartościami wejściowymi.

Nieruchomość jest członkiem, który zapewnia elastyczny mechanizm do odczytu, zapisu lub obliczyć wartość prywatnym terenie. Właściwości mogą być używane tak, jakby były publicznymi elementami danych, ale w rzeczywistości są to specjalne metody zwane akcesoriami . Umożliwia to łatwy dostęp do danych i nadal pomaga promować bezpieczeństwo i elastyczność metod . Właściwości umożliwiają klasie ujawnienie publicznego sposobu uzyskiwania i ustawiania wartości, jednocześnie ukrywając kod implementacyjny lub weryfikacyjny. Accessor własności get służy do zwrócenia wartości właściwości, a setor accessor służy do przypisania nowej wartości.

Właściwości mają tę podstawową zaletę, że umożliwiają zmianę sposobu dostępu do danych obiektu bez przerywania jego publicznego interfejsu. Na przykład, jeśli chcesz dodać dodatkowe sprawdzanie poprawności lub zmienić zapisane pole na obliczone, możesz to zrobić z łatwością, jeśli początkowo odsłoniłeś pole jako właściwość. Jeśli bezpośrednio odsłoniłeś pole, musisz zmienić publiczny interfejs swojej klasy, aby dodać nową funkcjonalność. Ta zmiana spowodowałaby uszkodzenie istniejących klientów, wymagając ich ponownej kompilacji, zanim będą mogli korzystać z nowej wersji kodu.

Jeśli napiszesz bibliotekę klas zaprojektowaną do powszechnego użytku (np. .NET Framework, z którego korzystają miliony ludzi), może to stanowić problem. Jednak jeśli piszesz klasę używaną wewnętrznie w małej bazie kodu (powiedzmy <= 50 K linii), to naprawdę nie jest wielka sprawa, ponieważ twoje zmiany nie wpłyną negatywnie na nikogo. W takim przypadku tak naprawdę sprowadza się to do osobistych preferencji.

Właściwości obsługują asymetryczny dostęp, tzn. Możesz mieć moduł pobierający i ustawiający lub tylko jeden z nich. Podobnie właściwości wspierają indywidualną dostępność dla gettera / settera. Pola są zawsze symetryczne, tzn. Zawsze można zarówno uzyskać, jak i ustawić wartość. Wyjątkiem są pola tylko do odczytu, których oczywiście nie można ustawić po inicjalizacji.

Właściwości mogą działać przez bardzo długi czas, mieć skutki uboczne, a nawet rzucać wyjątki. Pola są szybkie, bez skutków ubocznych i nigdy nie rzucą wyjątków. Ze względu na skutki uboczne właściwość może zwracać inną wartość dla każdego połączenia (jak może to mieć miejsce w przypadku DateTime.Now, tj. DateTime.Now nie zawsze jest równy DateTime.Now). Pola zawsze zwracają tę samą wartość.

Pola mogą być używane dla parametrów out / ref, właściwości mogą nie. Właściwości obsługują dodatkową logikę - można jej użyć między innymi do leniwego ładowania.

Właściwości obsługują poziom abstrakcji, ujmując wszystko, co oznacza pobranie / ustawienie wartości.

Używaj właściwości w większości / wszystkich przypadkach, ale staraj się unikać skutków ubocznych.

W tle właściwość jest kompilowana na metody. Tak więc Namewłaściwość jest wkompilowana w get_Name()i set_Name(string value). Możesz to zobaczyć, jeśli przestudiujesz skompilowany kod. Podczas korzystania z nich występuje (bardzo) niewielki narzut wydajności. Zwykle zawsze będziesz używać właściwości, jeśli wystawisz pole na zewnątrz i często będziesz używać go wewnętrznie, jeśli będziesz musiał dokonać walidacji wartości.

Jeśli chcesz, aby twoja prywatna zmienna (pole) była dostępna dla obiektu twojej klasy z innych klas, musisz utworzyć właściwości dla tych zmiennych.

na przykład, jeśli mam zmienne o nazwach „id” i „name”, które są prywatne, ale może się zdarzyć, że ta zmienna będzie potrzebna do operacji odczytu / zapisu poza klasą. W takiej sytuacji właściwość może mi pomóc w odczytaniu / zapisaniu tej zmiennej w zależności od zdefiniowanego dla tej właściwości parametru get / set. Właściwością może być zarówno readonly / writeonly / readwrite oba.

tutaj jest demo

class Employee
{
    // Private Fields for Employee
    private int id;
    private string name;

    //Property for id variable/field
    public int EmployeeId
    {
       get
       {
          return id;
       }
       set
       {
          id = value;
       }
    }

    //Property for name variable/field
    public string EmployeeName
    {
       get
       {
          return name;
       }
       set
       {
          name = value;
       }
   }
}

class MyMain
{
    public static void Main(string [] args)
    {
       Employee aEmployee = new Employee();
       aEmployee.EmployeeId = 101;
       aEmployee.EmployeeName = "Sundaran S";
    }
}

Drugie pytanie tutaj: „kiedy należy użyć pola zamiast właściwości?”, Jest tylko krótko poruszone w tej drugiej odpowiedzi i trochę tak samo , ale nie bardzo szczegółowe.

Ogólnie rzecz biorąc, wszystkie pozostałe odpowiedzi dotyczą trafnego projektu: wolą eksponowanie właściwości niż eksponowanie pól. Chociaż prawdopodobnie nie będziesz regularnie powtarzać: „wow, wyobraź sobie, o ile gorsze byłyby rzeczy, gdybym uczynił to pole zamiast własności”, jednak o wiele rzadziej jest myśleć o sytuacji, w której powiedziałbyś „wow, dzięki Bogu użyłem tu pola zamiast nieruchomości. ”

Ale jest jedna zaleta, że ​​pola mają właściwości, a jest to ich zdolność do wykorzystania jako parametry „ref” / „out”. Załóżmy, że masz metodę z następującym podpisem:

public void TransformPoint(ref double x, ref double y);

i załóżmy, że chcesz użyć tej metody do przekształcenia tablicy utworzonej w ten sposób:

System.Windows.Point[] points = new Point[1000000];
Initialize(points);

Oto, moim zdaniem, najszybszy sposób, aby to zrobić, ponieważ X i Y są właściwościami:

for (int i = 0; i < points.Length; i++)
{
    double x = points[i].X;
    double y = points[i].Y;
    TransformPoint(ref x, ref y);
    points[i].X = x;
    points[i].Y = y;
}

I to będzie całkiem niezłe! Chyba że masz pomiary, które dowodzą inaczej, nie ma powodu, aby smród. Uważam jednak, że technicznie nie jest tak szybki, jak to:

internal struct MyPoint
{
    internal double X;
    internal double Y;
}

// ...

MyPoint[] points = new MyPoint[1000000];
Initialize(points);

// ...

for (int i = 0; i < points.Length; i++)
{
    TransformPoint(ref points[i].X, ref points[i].Y);
}

Wykonując niektóre pomiary , wersja z polami zajmuje około 61% czasu w porównaniu z wersją z właściwościami (.NET 4.6, Windows 7, x64, tryb wydania, bez dołączonego debuggera). Im droższa TransformPointmetoda, tym mniej wyraźna staje się różnica. Aby powtórzyć to sam, biegnij z komentarzem pierwszego wiersza i bez komentarza.

Nawet jeśli powyższe nie przyniosłyby korzyści w zakresie wydajności, istnieją inne miejsca, w których użycie parametrów ref i out może być korzystne, na przykład podczas wywoływania rodziny metod Interlocked lub Volatile . Uwaga: W przypadku, gdy jest to dla ciebie nowość, Volatile jest zasadniczo sposobem na uzyskanie takiego samego zachowania, jakie zapewnia volatilesłowo kluczowe. Jako taki, volatilenie rozwiązuje w magiczny sposób wszystkich problemów związanych z bezpieczeństwem nici, jak sugeruje jego nazwa.

Zdecydowanie nie chcę wyglądać tak, jakbym opowiadał się za „och, powinienem zacząć odsłaniać pola zamiast właściwości”. Chodzi o to, że jeśli musisz regularnie używać tych członków w wywołaniach, które przyjmują parametry „ref” lub „out”, szczególnie w przypadku czegoś, co może być prostym typem wartości, który prawdopodobnie nigdy nie potrzebuje żadnego z elementów wartości dodanej właściwości, można argumentować.

Chociaż pola i właściwości wydają się do siebie podobne, są to 2 zupełnie różne elementy językowe.

1. Pola są jedynym mechanizmem przechowywania danych na poziomie klasy. Pola są zmiennymi koncepcyjnie w zakresie klasy. Jeśli chcesz przechowywać niektóre dane w instancjach swoich klas (obiektów), musisz użyć pól. Nie ma innego wyboru. Właściwości nie mogą przechowywać żadnych danych, choć może się wydawać, że są w stanie to zrobić. Patrz poniżej.

2. Z drugiej strony właściwości nigdy nie przechowują danych. Są to tylko pary metod (get i set), które można syntaktycznie wywoływać w podobny sposób jak pola, aw większości przypadków uzyskują dostęp (do odczytu lub zapisu) do pól, co jest źródłem pewnych nieporozumień. Ale ponieważ metody własności są (z pewnymi ograniczeniami, takimi jak stały prototyp) zwykłymi metodami C #, mogą robić to, co mogą zrobić zwykłe metody. Oznacza to, że mogą mieć 1000 linii kodu, mogą zgłaszać wyjątki, wywoływać inne metody, mogą być nawet wirtualne, abstrakcyjne lub przesłonięte. Tym, co wyróżnia właściwości, jest fakt, że kompilator C # przechowuje dodatkowe metadane w zestawach, których można użyć do wyszukiwania określonych właściwości - funkcja powszechnie używana.

Pobierz i ustaw metody właściwości ma następujące prototypy.

PROPERTY_TYPE get();

void set(PROPERTY_TYPE value);

Oznacza to, że właściwości mogą być „emulowane” poprzez zdefiniowanie pola i 2 odpowiednich metod.

class PropertyEmulation
{
    private string MSomeValue;

    public string GetSomeValue()
    {
        return(MSomeValue);
    }

    public void SetSomeValue(string value)
    {
        MSomeValue=value;
    }
}

Taka emulacja właściwości jest typowa dla języków programowania, które nie obsługują właściwości - takich jak standardowy C ++. W języku C # zawsze powinieneś preferować właściwości jako sposób dostępu do swoich pól.

Ponieważ tylko pola mogą przechowywać dane, oznacza to, że więcej klas pól zawiera, więcej obiektów pamięci takiej klasy zużyje. Z drugiej strony dodanie nowych właściwości do klasy nie powoduje powiększenia obiektów tej klasy. Oto przykład.

class OneHundredFields
{
        public int Field1;
        public int Field2;
        ...
        public int Field100;
}

OneHundredFields Instance=new OneHundredFields() // Variable 'Instance' consumes 100*sizeof(int) bytes of memory.

class OneHundredProperties
{
    public int Property1
    {
        get
        {
            return(1000);
        }
        set
        {
            // Empty.
        }
    }

    public int Property2
    {
        get
        {
            return(1000);
        }
        set
        {
            // Empty.
        }
    }

    ...

    public int Property100
    {
        get
        {
            return(1000);
        }
        set
        {
            // Empty.
        }
    }
}

OneHundredProperties Instance=new OneHundredProperties() // !!!!! Variable 'Instance' consumes 0 bytes of memory. (In fact a some bytes are consumed becasue every object contais some auxiliarity data, but size doesn't depend on number of properties).

Chociaż metody własności mogą zrobić wszystko, w większości przypadków służą one do uzyskiwania dostępu do pól obiektów. Jeśli chcesz, aby pole było dostępne dla innych klas, możesz to zrobić na dwa sposoby.

1. Upublicznianie pól - niewskazane.
2. Korzystanie z właściwości.

Oto klasa wykorzystująca pola publiczne.

class Name
{
    public string FullName;
    public int YearOfBirth;
    public int Age;
}

Name name=new Name();

name.FullName="Tim Anderson";
name.YearOfBirth=1979;
name.Age=40;

Chociaż kod jest całkowicie poprawny, z punktu widzenia projektu ma kilka wad. Ponieważ pola można zarówno odczytywać, jak i zapisywać, nie można uniemożliwić użytkownikowi pisania do pól. Możesz zastosować readonlysłowo kluczowe, ale w ten sposób musisz zainicjować pola tylko do odczytu tylko w konstruktorze. Co więcej, nic nie stoi na przeszkodzie, aby przechowywać niepoprawne wartości w swoich polach.

name.FullName=null;
name.YearOfBirth=2200;
name.Age=-140;

Kod jest prawidłowy, wszystkie zadania zostaną wykonane, choć są nielogiczne. Agema wartość ujemną, YearOfBirthjest daleko w przyszłości i nie odpowiada Wiekowi i FullNamejest zerowy. Za pomocą pól nie można zapobiec class Namepopełnianiu takich błędów przez użytkowników.

Oto kod z właściwościami, które rozwiązują te problemy.

class Name
{
    private string MFullName="";
    private int MYearOfBirth;

    public string FullName
    {
        get
        {
            return(MFullName);
        }
        set
        {
            if (value==null)
            {
                throw(new InvalidOperationException("Error !"));
            }

            MFullName=value;
        }
    }

    public int YearOfBirth
    {
        get
        {
            return(MYearOfBirth);
        }
        set
        {
            if (MYearOfBirth<1900 || MYearOfBirth>DateTime.Now.Year)
            {
                throw(new InvalidOperationException("Error !"));
            }

            MYearOfBirth=value;
        }
    }

    public int Age
    {
        get
        {
            return(DateTime.Now.Year-MYearOfBirth);
        }
    }

    public string FullNameInUppercase
    {
        get
        {
            return(MFullName.ToUpper());
        }
    }
}

Zaktualizowana wersja klasy ma następujące zalety.

1. FullNamei YearOfBirthsą sprawdzane pod kątem nieprawidłowych wartości.
2. Agenie jest zapisywalny. Jest obliczany od YearOfBirthbieżącego roku.
3. Nowa właściwość jest FullNameInUppercasekonwertowana FullNamena UPPER CASE. Jest to trochę wymyślony przykład użycia właściwości, w którym właściwości są powszechnie używane do prezentacji wartości pól w formacie bardziej odpowiednim dla użytkownika - na przykład przy użyciu bieżących ustawień regionalnych dla określonej liczby DateTimeformatów.

Poza tym właściwości można zdefiniować jako wirtualne lub zastąpione - po prostu dlatego, że są to zwykłe metody .NET. Te same zasady dotyczą takich metod własności, jak w przypadku metod zwykłych.

C # obsługuje również indeksatory, które są właściwościami, które mają parametr indeksu w metodach właściwości. Oto przykład.

class MyList
{
    private string[]                 MBuffer;

    public MyList()
    {
        MBuffer=new string[100];
    }

    public string this[int Index]
    {
        get
        {
            return(MBuffer[Index]);
        }
        set
        {
            MBuffer[Index]=value;
        }
    }
}

MyList   List=new MyList();

List[10]="ABC";
Console.WriteLine(List[10]);

Ponieważ C # 3.0 pozwala zdefiniować właściwości automatyczne. Oto przykład.

class AutoProps
{
    public int Value1
    {
        get;
        set;
    }

    public int Value2
    {
        get;
        set;
    }
}

Mimo że class AutoPropszawiera tylko właściwości (lub tak wygląda), może przechowywać 2 wartości, a wielkość obiektów tej klasy jest równa sizeof(Value1)+sizeof(Value2)= 4 + 4 = 8 bajtów.

Powód tego jest prosty. Po zdefiniowaniu właściwości automatycznej kompilator C # generuje kod automatyczny zawierający ukryte pole oraz właściwość z metodami właściwości umożliwiającymi dostęp do tego ukrytego pola. Oto kompilator kodu, który produkuje.

Oto kod wygenerowany przez ILSpy ze skompilowanego zestawu. Klasa zawiera wygenerowane ukryte pola i właściwości.

internal class AutoProps
{
    [CompilerGenerated]
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private int <Value1>k__BackingField;

    [CompilerGenerated]
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private int <Value2>k__BackingField;

    public int Value1
    {
        [CompilerGenerated]
        get
        {
            return <Value1>k__BackingField;
        }
        [CompilerGenerated]
        set
        {
            <Value1>k__BackingField = value;
        }
    }

    public int Value2
    {
        [CompilerGenerated]
        get
        {
            return <Value2>k__BackingField;
        }
        [CompilerGenerated]
        set
        {
            <Value2>k__BackingField = value;
        }
    }
}

Jak więc widać, kompilator nadal używa pól do przechowywania wartości - ponieważ pola są jedynym sposobem przechowywania wartości w obiektach.

Jak widać, chociaż właściwości i pola mają podobną składnię użycia, są to bardzo różne pojęcia. Nawet jeśli korzystasz z automatycznych właściwości lub zdarzeń - ukryte pola są generowane przez kompilator, w którym przechowywane są rzeczywiste dane.

Jeśli chcesz, aby wartość pola była dostępna dla świata zewnętrznego (użytkownicy twojej klasy), nie używaj pól publicznych ani chronionych. Pola zawsze powinny być oznaczone jako prywatne. Właściwości pozwalają na sprawdzanie wartości, formatowanie, konwersje itp. I ogólnie sprawiają, że kod jest bezpieczniejszy, bardziej czytelny i rozszerzalny dla przyszłych modyfikacji.

Ponadto właściwości pozwalają używać logiki podczas ustawiania wartości.

Możesz więc powiedzieć, że chcesz ustawić wartość w polu liczby całkowitej, jeśli wartość jest większa niż x, w przeciwnym razie wyrzuć wyjątek.

Naprawdę przydatna funkcja.

Jeśli zamierzasz używać prymitywów wątku, musisz użyć pól. Właściwości mogą uszkodzić kod wątkowy. Poza tym to, co powiedział Cory, jest poprawne.

(To naprawdę powinien być komentarz, ale nie mogę opublikować komentarza, więc przepraszam, jeśli nie jest odpowiedni jako post).

Kiedyś pracowałem w miejscu, w którym zalecaną praktyką było użycie pól publicznych zamiast właściwości, gdy równoważna właściwość def miałaby dostęp do pola, jak w:

get { return _afield; }
set { _afield = value; }

Ich rozumowanie było takie, że w razie potrzeby pole publiczne można przekształcić w właściwość w przyszłości. Wtedy wydawało mi się to trochę dziwne. Sądząc po tych postach, wygląda na to, że niewielu tutaj też się zgodzi. Co mogłeś powiedzieć, żeby spróbować coś zmienić?

Edycja: Powinienem dodać, że cała baza kodu w tym miejscu została skompilowana w tym samym czasie, więc mogliby pomyśleć, że zmiana publicznego interfejsu klas (przez zmianę pola publicznego na właściwość) nie stanowi problemu.

Technicznie rzecz biorąc, nie sądzę, że istnieje różnica, ponieważ właściwości są tylko opakowaniami wokół pól utworzonych przez użytkownika lub automatycznie utworzonych przez kompilator. Celem właściwości jest wymuszenie enkapsulacji i zaoferowanie lekkiej funkcji podobnej do metody. Deklarowanie pól jako publicznych jest po prostu złą praktyką, ale nie ma żadnych problemów.

Pola są zwykłymi zmiennymi składowymi lub instancjami składowymi klasy. Właściwości są abstrakcją pozwalającą uzyskać i ustawić ich wartości . Właściwości nazywane są także akcesoriami, ponieważ oferują sposób zmiany i pobrania pola, jeśli ujawnisz pole w klasie jako prywatne. Zasadniczo powinieneś zadeklarować swoje zmienne składowe jako prywatne, a następnie zadeklarować lub zdefiniować dla nich właściwości.

  class SomeClass
  {
     int numbera; //Field

     //Property 
    public static int numbera { get; set;}

  }

Właściwości otaczają pola, umożliwiając w ten sposób dodatkowe przetwarzanie wartości, którą należy ustawić lub pobrać. Zazwyczaj używanie właściwości jest przesadą, jeśli nie będziesz wykonywać żadnego przetwarzania wstępnego ani końcowego na wartości pola.

IMO, Właściwości to tylko pary funkcji / metod / interfejsów „SetXXX ()” „GetXXX ()”, których używaliśmy wcześniej, ale są bardziej zwięzłe i eleganckie.

Tradycyjnie prywatne pola są ustawiane za pomocą metod pobierających i ustawiających. Ze względu na mniej kodu możesz zamiast tego używać właściwości do ustawiania pól.

kiedy masz klasę, którą jest „samochód”. Właściwości to kolor, kształt ..

Gdzie jako pola są zmienne zdefiniowane w ramach klasy.

Z Wikipedii - Programowanie obiektowe :

Programowanie obiektowe (OOP) to paradygmat programowania oparty na koncepcji „obiektów”, które są strukturami danych zawierającymi dane w postaci pól , często nazywanych atrybutami; i kod w postaci procedur, często znanych jako metody . (podkreślenie dodane)

Właściwości są w rzeczywistości częścią zachowania obiektu, ale mają na celu dać konsumentom obiektu iluzję / abstrakcję pracy z danymi obiektu.

Mój projekt pola polega na tym, że pole musi być modyfikowane tylko przez jego element nadrzędny, stąd klasa. Wynik zmienna staje się prywatna, a następnie, aby móc dać prawo do odczytu klas / metod poza, przechodzę przez system własności tylko z Get. Pole jest następnie pobierane przez właściwość i tylko do odczytu! Jeśli chcesz go zmodyfikować, musisz przejść przez metody (na przykład konstruktor) i stwierdzam, że dzięki temu sposobowi zapewnienia ci bezpieczeństwa mamy lepszą kontrolę nad naszym kodem, ponieważ „flange”. Bardzo dobrze można zawsze podawać wszystko do wiadomości publicznej, więc każdy możliwy przypadek, pojęcie zmiennych / metod / klas itp. Moim zdaniem jest po prostu pomocą w rozwoju, utrzymaniu kodu. Na przykład, jeśli ktoś wznowi kod z polami publicznymi, może zrobić wszystko, a zatem rzeczy „nielogiczne” w odniesieniu do celu logika, dlaczego kod został napisany. To mój punkt widzenia.

Kiedy używam klasycznego modelu prywatnego pola / publicznych właściwości tylko do odczytu, dla 10 prywatnych pól powinienem napisać 10 właściwości publicznych! Kod może być naprawdę duży szybciej. Odkrywam prywatnego setera i teraz używam tylko publicznych właściwości z prywatnym seterem. Seter tworzy w tle prywatne pole.

Właśnie dlatego moim starym klasycznym stylem programowania było:

public class MyClass
{
 private int _id;
 public int ID { get { return _id; } }
 public MyClass(int id)
 {
  _id = id;
 }
}

Mój nowy styl programowania:

public class MyClass
{
 public int ID { get; private set; }
 public MyClass(int id)
 {
  ID = id;
 }
}

Pomyśl o tym: masz pokój i drzwi, aby wejść do tego pokoju. Jeśli chcesz sprawdzić, kto wchodzi i zabezpieczyć swój pokój, powinieneś użyć właściwości, w przeciwnym razie nie będą to żadne drzwi i każdy z łatwością wejdzie bez żadnych regulacji

class Room {
   public string sectionOne;
   public string sectionTwo;
}

Room r = new Room();
r.sectionOne = "enter";

Ludzie dostają się do sekcji Jeden bardzo łatwo, nie było żadnej kontroli

class Room 
{
   private string sectionOne;
   private string sectionTwo;

   public string SectionOne 
   {
      get 
      {
        return sectionOne; 
      }
      set 
      { 
        sectionOne = Check(value); 
      }
   }
}

Room r = new Room();
r.SectionOne = "enter";

Teraz sprawdziłeś osobę i wiesz, czy ma z nią coś złego

Pola są zmiennymi w klasach. Pola to dane, które można enkapsulować za pomocą modyfikatorów dostępu.

Właściwości są podobne do pól, ponieważ definiują stany i dane powiązane z obiektem.

W przeciwieństwie do pola właściwość ma specjalną składnię, która kontroluje sposób, w jaki osoba czyta dane i zapisuje dane, są one znane jako operatory get i set. Ustawionej logiki można często używać do sprawdzania poprawności.

Właściwości są szczególnym rodzajem członka klasy. We właściwościach używamy predefiniowanej metody Set lub Get. Korzystają one z akcesoriów, dzięki którym możemy odczytywać, zapisywać lub zmieniać wartości pól prywatnych.

Weźmy na przykład klasę o nazwie Employee z prywatnymi polami na imię, wiek i identyfikator pracownika. Nie możemy uzyskać dostępu do tych pól spoza klasy, ale możemy uzyskać dostęp do tych prywatnych pól poprzez właściwości.

Dlaczego korzystamy z nieruchomości?

Upublicznienie pola klasy i ujawnienie go jest ryzykowne, ponieważ nie będziesz mieć kontroli nad tym, co zostanie przypisane i zwrócone.

Aby to jasno zrozumieć na przykładzie, weźmy klasę studencką, która ma identyfikator, hasło, imię i nazwisko. Teraz w tym przykładzie jakiś problem z polem publicznym

• ID nie powinno być -ve.
• Nazwa nie może być ustawiona na null
• Znak zaliczenia powinien być tylko do odczytu.
• Jeśli brakuje nazwiska studenta, nie należy zwracać nazwiska.

Aby usunąć ten problem, korzystamy z metody Get and set.

// A simple example
public class student
{
    public int ID;
    public int passmark;
    public string name;
}

public class Program
{
    public static void Main(string[] args)
    {
       student s1 = new student();
       s1.ID = -101; // here ID can't be -ve
       s1.Name = null ; // here Name can't be null
    }
}

Teraz bierzemy przykład metody get and set

public class student
{
    private int _ID;
    private int _passmark;
    private string_name ;
    // for id property
    public void SetID(int ID)
    {
        if(ID<=0)
        {
            throw new exception("student ID should be greater then 0");
        }
        this._ID = ID;
    }
    public int getID()
    {
        return_ID;
    }
}
public class programme
{
    public static void main()
    {
        student s1 = new student ();
        s1.SetID(101);
    }
    // Like this we also can use for Name property
    public void SetName(string Name)
    {
        if(string.IsNullOrEmpty(Name))
        {
            throw new exeception("name can not be null");
        }
        this._Name = Name;
    }
    public string GetName()
    {
        if( string.IsNullOrEmpty(This.Name))
        {
            return "No Name";
        }
        else
        {
            return this._name;
        }
    }
        // Like this we also can use for Passmark property
    public int Getpassmark()
    {
        return this._passmark;
    }
}

Informacje dodatkowe: Domyślnie dostęp i dostęp do akcesoriów są tak samo dostępne, jak sama właściwość. Możesz kontrolować / ograniczać dostępność akcesorium indywidualnie (w celu uzyskania i ustawienia), stosując na nich bardziej restrykcyjne modyfikatory dostępu.

Przykład:

public string Name
{
    get
    {
        return name;
    }
    protected set
    {
        name = value;
    }
}

Tutaj get jest nadal publicznie dostępny (ponieważ właściwość jest publiczna), ale zestaw jest chroniony (bardziej ograniczony specyfikator dostępu).

Właściwości służą do wyświetlania pola. Używają akcesoriów (ustaw, pobierz), dzięki którym można odczytać, zapisać lub manipulować wartościami pól prywatnych.

Właściwości nie nazywają lokalizacji przechowywania. Zamiast tego mają akcesoria, które odczytują, zapisują lub obliczają swoje wartości.

Za pomocą właściwości możemy ustawić sprawdzanie poprawności typu danych ustawionych w polu.

Na przykład mamy prywatny wiek pola liczb całkowitych, na którym powinniśmy dopuszczać wartości dodatnie, ponieważ wiek nie może być ujemny.

Możemy to zrobić na dwa sposoby, używając gettera i settera oraz używając własności.

 Using Getter and Setter

    // field
    private int _age;

    // setter
    public void set(int age){
      if (age <=0)
       throw new Exception();

      this._age = age;
    }

    // getter
    public int get (){
      return this._age;
    }

 Now using property we can do the same thing. In the value is a key word

    private int _age;

    public int Age{
    get{
        return this._age;
    }

    set{
       if (value <= 0)
         throw new Exception()
       }
    }

Właściwość zaimplementowana automatycznie, jeśli nie logujemy się w uzyskiwaniu i ustawianiu akcesoriów, możemy użyć właściwości zaimplementowanej automatycznie.

Gdy użyjesz automatycznie zaimplementowanej kompilacji właściwości, tworzy prywatne, anonimowe pole, do którego można uzyskać dostęp tylko poprzez get i set accessors.

public int Age{get;set;}

Właściwości abstrakcyjne Klasa abstrakcyjna może mieć właściwość abstrakcyjną, którą należy zaimplementować w klasie pochodnej

public abstract class Person
   {
      public abstract string Name
      {
         get;
         set;
      }
      public abstract int Age
      {
         get;
         set;
      }
   }

// overriden something like this
// Declare a Name property of type string:
  public override string Name
  {
     get
     {
        return name;
     }
     set
     {
        name = value;
     }
  }

Możemy prywatnie ustawić właściwość W tym możemy prywatnie ustawić właściwość auto (ustawić za pomocą w klasie)

public int MyProperty
{
    get; private set;
}

Możesz osiągnąć to samo dzięki temu kodowi. W tym zestawie właściwości funkcja nie jest dostępna, ponieważ musimy ustawić wartość bezpośrednio w polu.

private int myProperty;
public int MyProperty
{
    get { return myProperty; }
}

W zdecydowanej większości przypadków będzie to nazwa właściwości, do której można uzyskać dostęp, a nie nazwa zmiennej ( pole ). Powodem tego jest uważana za dobrą praktykę w .NET, aw szczególności w C #, w celu ochrony każdego elementu danych w klasie , niezależnie od tego, czy jest to zmienna instancji, czy zmienna statyczna (zmienna klasy), ponieważ jest powiązana z klasą.

Chroń wszystkie te zmienne odpowiednimi właściwościami, które pozwalają definiować, ustawiać i uzyskiwać akcesoria oraz wykonywać takie czynności, jak sprawdzanie poprawności podczas manipulowania tymi częściami danych.

Ale w innych przypadkach, takich jak klasa Math (przestrzeń nazw systemu), istnieje kilka właściwości statycznych wbudowanych w klasę. jednym z nich jest stała matematyczna PI

na przykład. Math.PI

a ponieważ PI jest dobrze zdefiniowanym fragmentem danych, nie musimy mieć wielu kopii PI, zawsze będzie miała tę samą wartość. Tak więc zmienne statyczne są czasami używane do udostępniania danych między obiektami klasy, ale są również powszechnie używane do ciągłej informacji, gdzie potrzebujesz tylko jednej kopii fragmentu danych.