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

Zasady programowania zorientowanego obiektowo mówią, że wewnętrzne działanie klasy powinno być ukryte przed światem zewnętrznym. Jeśli ujawniasz pole, w istocie ujawniasz wewnętrzną implementację klasy. Dlatego owijamy pola właściwościami (lub metodami w przypadku Javy), aby dać nam możliwość zmiany implementacji bez łamania kodu w zależności od nas. Widząc, że możemy umieścić logikę we właściwości, możemy również wykonać logikę walidacji itp., Jeśli tego potrzebujemy. C # 3 ma prawdopodobnie mylące pojęcie autoproperties. To pozwala nam po prostu zdefiniować Właściwość i kompilator C#3 wygeneruje dla nas pole prywatne.

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, dla 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 funkcjach klasy. Z reguły rzadko tworzę publiczne pola i podobnie rzadko tworzę Niepubliczne właściwości.

Dam ci kilka przykładów użycia właściwości, które mogą sprawić, że koła zębate się obracają:

• leniwa Inicjalizacja: Jeśli masz właściwość obiektu, który jest drogi w załadowaniu, ale nie ma do niego dostępu w normalnych uruchomieniach kodu, możesz opóźnić jego załadowanie za pomocą 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 podstawowe pole jest null - jeśli tak, to przechodzi do przodu i ładuje je, nieznany moduł wywołujący. Może to znacznie przyspieszyć inicjalizację obiektu.
• Dirty Tracking: o czym właściwie dowiedziałem się z mojegowłasnego pytania tutaj na StackOverflow. Gdy mam wiele obiektów, których wartości mogły ulec zmianie podczas uruchamiania, mogę użyć właściwości do śledzenia, czy muszą być zapisane z powrotem do bazy danych, czy nie. Jeśli żadna właściwość obiektu nie uległa zmianie, flaga IsDirty nie zostanie potknięta, a zatem funkcja zapisywania pomiń to przy podejmowaniu decyzji, co musi wrócić do bazy danych.

Używając właściwości, możesz rzucić zdarzenie, gdy wartość właściwości zostanie zmieniona (aka . PropertyChangedEvent) lub przed zmianą wartości na wsparcie anulowania.

Nie jest to możliwe w przypadku pól (bezpośredniego dostępu 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(){
   EventHandler localEvent = NameChanging;
   if (localEvent != null) {
     localEvent(this,EventArgs.Empty);
   }
 }

 private void OnNameChanged(){
   EventHandler localEvent = NameChanged;
   if (localEvent != null) {
     localEvent(this,EventArgs.Empty);
   }
 }
}

Ponieważ wiele z nich wyjaśniło techniczne wady i zalety Properties i Field, nadszedł czas, aby przejść do przykładów w czasie rzeczywistym.

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

Rozważmy przypadek dataTable.Rows.Count i dataTable.Columns[i].Caption. Pochodzą z klasy DataTable i obie są dla nas publiczne. Różnica w poziomie dostępu do nich polega na tym, że nie możemy ustawić wartości na dataTable.Rows.Count, ale możemy odczytywać i zapisywać na dataTable.Columns[i].Caption. Czy jest to możliwe poprzez Field? Nie!!! Można to zrobić tylko z Properties.

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

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 zostaną pokazane właściwości Name i Text, ale nie SomeProperty. Dlaczego??? Ponieważ właściwości mogą przyjmować atrybuty . Nie pokazuje się w przypadku, gdy [Browsable(false)] jest false.

3. Może wykonywać polecenia wewnątrz 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 źródle wiązania

Binding Source pomaga nam zmniejszyć liczbę linii kodu. Fields nie są akceptowane przez BindingSource. Powinniśmy do tego użyć Properties.

5. Tryb debugowania

Rozważmy używa Field do przechowywania wartości. W pewnym momencie musimy debugować i sprawdzić, gdzie wartość otrzymuje null dla tego pola. Będzie to trudne do zrobienia, gdy liczba linii kodu jest większa niż 1000. W takich sytuacjach możemy użyć Property i 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)

A pole jest zmienną zadeklarowaną bezpośrednio w klasie lub strukturze. Klasa lub struktura mogą mieć pola instancji lub statyczne lub oba te pola. Ogólnie rzecz biorąc, należy używać pól tylko dla zmiennych, które mają dostęp prywatny lub chroniony . Dane, które Twoja klasa wystawia na kod klienta powinny być dostarczane za pomocą metod, właściwości i indeksatorów. Korzystając z tych konstrukcji do pośredniego dostępu do pól wewnętrznych, można ochrona przed nieprawidłowymi wartościami wejściowymi.

A właściwość jest elementem zapewniającym elastyczny mechanizm odczytu, zapisu lub obliczania wartości pola prywatnego. Właściwości mogą być używane tak, jakby były public data member, ale w rzeczywistości są to specjalne metody zwane accesorami . 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, podczas gdy ukrywanie implementacji lub kodu weryfikacyjnego. Get property accessor jest używany do zwracania wartości właściwości, a set accessor jest używany do przypisywania nowej wartości.

Właściwości mają podstawową zaletę pozwalającą na zmianę sposobu dostępu do danych obiektu bez naruszania jego publicznego interfejsu. Na przykład, jeśli chcesz dodać dodatkową walidację lub zmienić pole zapisane na obliczone, możesz to zrobić łatwo, jeśli początkowo wystawiono pole jako właściwość. Jeśli po prostu odsłonisz pole bezpośrednio, będziesz musiał zmienić publiczny interfejs swojej klasy, aby dodać nową funkcjonalność. Zmiana ta złamałaby dotychczasowych klientów, wymaga ich przekompilowania, zanim będą mogli użyć nowej wersji Twojego kodu.

Jeśli napiszesz bibliotekę klas przeznaczoną do szerokiego użytku (jak.NET Framework, który jest używany przez miliony ludzi), może to być problem. Jednakże, jeśli piszesz klasę używaną wewnętrznie wewnątrz małej bazy kodu (powiedzmy

W tle właściwość jest kompilowana do metod. Tak więc Właściwość Name jest kompilowana do get_Name() i set_Name(string value). Możesz to zobaczyć, jeśli przestudiujesz skompilowany kod. Tak więc podczas ich używania występuje (bardzo) mała wydajność. Zwykle zawsze będziesz używać właściwości, jeśli wystawisz pole Na zewnątrz, i często będziesz używać jej wewnętrznie, jeśli musisz wykonać walidację wartości.

Właściwości obsługują dostęp asymetryczny, tzn. możesz mieć getter i setter lub tylko jeden z dwóch. Podobnie właściwości wspierają indywidualną dostępność dla getter/setter. Pola są zawsze symetryczne, tzn. zawsze można uzyskać 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ć bardzo długo, mieć skutki uboczne, a nawet rzucać wyjątki. Pola są szybkie, bez skutków ubocznych, i nigdy nie rzuci WYJĄTKÓW. Ze względu na skutki uboczne właściwość może zwracać inną wartość dla każdego wywołania (tak jak w przypadku DateTime.Teraz, czyli DateTime.Now nie zawsze jest równa DateTime.Teraz). 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 wspierają dodatkową logikę – można to wykorzystać m.in. do implementacji leniwego ładowania.

Właściwości wspierają poziom abstrakcji poprzez enkapsulację dowolnego to znaczy, aby uzyskać / ustawić wartość.

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

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 nazwane jako " 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 , property może pomóc mi uzyskać tę zmienną do odczytu/zapisu w zależności od get / set zdefiniowanego dla właściwości. Nieruchomość może być zarówno readonly / writeonly / readwrite.

Oto 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 powinno być używane pole zamiast właściwości?", jest tylko krótko poruszony w tej drugiej odpowiedzi i trochę tej też, ale niewiele szczegółów.

Ogólnie rzecz biorąc, wszystkie inne odpowiedzi są trafne na temat dobrego projektu: preferują eksponowanie właściwości niż eksponowanie pól. Chociaż prawdopodobnie nie będziesz regularnie mówić: "wow, wyobraź sobie, jak wiele gorszych rzeczy byłoby, gdybym zrobił to pole zamiast własności", to jest tak wiele rzadsze myśleć o sytuacji, w której można powiedzieć " wow, dzięki Bogu użyłem pola tutaj zamiast własności."

Ale jest jedna zaleta, że pola mają przewagę nad właściwościami, a jest to ich zdolność do używania jako parametrów " 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 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! Jeśli nie masz pomiarów, które udowodnią, że jest inaczej, nie ma powodu, aby rzucać smrodem. Ale uważam, że nie jest to technicznie gwarantowane tak szybko 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 pomiary , wersja z polami zajmuje około 61% czasu jako wersja z właściwościami (. NET 4.6, Windows 7, x64, tryb Wydania, bez dołączonego debuggera). Im droższe tym TransformPoint metoda dostaje, tym mniej wyraźna staje się różnica. Aby powtórzyć to samemu, Uruchom z pierwszą linią skomentowaną, a z nią nie skomentowaną.

Nawet jeśli nie było żadnych korzyści wydajnościowych dla powyższego, istnieją inne miejsca, w których możliwość korzystania z parametrów ref i out może być korzystna, na przykład podczas wywoływania Interlocked lub Volatile rodzina metod. Uwaga: w przypadku, gdy jest to dla Ciebie nowe, Lotne jest w zasadzie sposobem, aby dostać się na takie samo zachowanie zapewnia słowo kluczowe volatile. Jako taki, jak volatile, nie rozwiązuje magicznie wszystkich problemów związanych z bezpieczeństwem, jak sugeruje jego nazwa.

Zdecydowanie nie chcę wydawać się, że opowiadam się za tym, abyś powiedział: "Och, powinienem zacząć eksponować 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 na czymś, co może być prostym typem wartości, które jest mało prawdopodobne, aby kiedykolwiek potrzebowały któregokolwiek z wartości dodanej elementów właściwości, argument może być wykonany.

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

Możesz więc powiedzieć, że chcesz ustawić wartość na pole integer tylko wtedy, gdy wartość jest większa niż x, w przeciwnym razie wyrzuć wyjątek.

Naprawdę przydatna funkcja.

Jeśli zamierzasz używać primitives wątku, musisz użyć pól. Właściwości mogą złamać kod gwintowany. Poza tym, to co powiedział cory jest poprawne.

(to naprawdę powinien być komentarz, ale nie mogę zamieścić komentarz, więc proszę wybaczyć, jeśli nie jest odpowiedni jako post).

Kiedyś pracowałem w miejscu, gdzie zalecaną praktyką było używanie publicznych pól 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 polegało na tym, że pole publiczne może zostać przekształcone w nieruchomość w przyszłości, jeśli zajdzie taka potrzeba. Wydawało mi się to wtedy trochę dziwne. Ocenianie po tych postach wygląda na to, że nie wielu tutaj też by się zgodziło. Co mogłeś powiedzieć, żeby coś zmienić ?

Edit: powinienem dodać, że cała baza kodu w tym miejscu została skompilowana w tym samym czasie, więc mogli pomyśleć, że zmiana publicznego interfejsu klas (poprzez zmianę publicznego pola na właściwość) nie była problemem.

Ta strona na MSDN ma porównanie i wskazówki, które z nich użyć, gdy:

Https://msdn.microsoft.com/en-us/library/9d65as2e (v=vs.90). aspx

Pola są zwykłymi zmiennymi składowymi lub instancjami składowymi klasy. Właściwości są abstrakcją do uzyskania i ustawienia ich wartości . Właściwości są również nazywane accessorami, ponieważ oferują sposób na zmianę i odzyskanie pola, jeśli wystawisz pole w klasie jako prywatne. Ogólnie rzecz biorąc, powinieneś zadeklarować swoje zmienne członkowskie 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 hermetyzują pola, umożliwiając w ten sposób dodatkowe przetwarzanie wartości, która ma być ustawiona lub pobrana. Zazwyczaj używanie właściwości jest przesadą, jeśli nie będziesz robił żadnego wstępnego lub postprocessingu na wartości pola.

Technicznie rzecz biorąc, nie sądzę, aby istniała 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 enkapsuacji i zaoferowanie lekkiej funkcji podobnej do metody. Deklarowanie pól jako publicznych jest po prostu złą praktyką, ale nie ma żadnych problemów.

IMO, właściwości są po prostu parami" SetXXX () "" GetXXX () " funkcje / metody/interfejsy, których używaliśmy wcześniej, ale są bardziej zwięzłe i eleganckie.

Tradycyjnie prywatne pola są ustawiane za pomocą metod getter i setter. Ze względu na mniejszą ilość kodu można używać właściwości do ustawiania pól.

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

Gdzie pola as są zmiennymi zdefiniowanymi w ramach klasy.

Z Wikipedii -- Programowanie obiektowe :

Programowanie obiektowe (ang. Object-oriented programming, OOP) - paradygmat programowania oparty na pojęciu "obiektów", które są strukturami danych, które zawierają DANE, w postaci pól, często zwanych atrybutami; oraz kod, w postaci procedur, często zwanych metodami. (podkreślenie dodane)

Właściwości są rzeczywiście częścią zachowania obiektu, ale są zaprojektowane tak, aby dać konsumentom obiekt iluzja / abstrakcja pracy z danymi obiektu.

Właściwości są specjalnym rodzajem klasy, we właściwościach używamy predefiniowanej metody Set lub Get.Używają accesorów, za pomocą których możemy odczytywać, zapisywać lub zmieniać wartości pól prywatnych.

Na przykład, weźmy klasę o nazwie Employee, z prywatnymi polami dla name, age I Employee_Id. 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 używamy właściwości?

Tworzenie pola klasy publiczne i ujawnianie tego jest ryzykowne, ponieważ nie będziesz miał kontroli nad tym, co zostanie przypisane i zwrócone.

Aby zrozumieć to wyraźnie za pomocą przykładu, weźmy klasę studencką, która ma ID, passmark, imię. W tym przykładzie problem z polem publicznym

• ID nie powinno być-ve.
• nazwa nie może być ustawiona na null
• Pass mark powinien być tylko do odczytu.
• Jeśli brakuje nazwiska ucznia, żadne Imię nie powinno być zwracane.

Aby usunąć ten problem używamy Get i set method.

// 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 I 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;
    }
}

Mój projekt pola polega na tym, że pole musi być modyfikowane tylko przez jego rodzica, stąd Klasa. Wynik zmienna staje się prywatna, wtedy aby móc dać prawo do odczytu klas / metod poza i przejść przez system właściwoś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 uważam, że dzięki temu sposobowi zabezpieczenia mamy lepszą kontrolę nad nasz kod, ponieważ"kołnierz". Można bardzo dobrze zawsze umieścić wszystko publicznie, więc każdy możliwy przypadek, pojęcie zmiennych / metod / klas itp ... moim zdaniem jest to tylko pomoc w rozwoju, utrzymaniu kodu. Na przykład, jeśli dana osoba wznawia kod z publicznymi polami, może zrobić wszystko, a zatem rzeczy "nielogiczne" w odniesieniu do celu, logiki, dlaczego kod został napisany. To mój punkt widzenia.

Kiedy używam klasycznego modelu private field / public readonly properties, for 10 privates fields I should write 10 public properties! Kod może być naprawdę duży szybciej. Odkrywam prywatny setter i teraz używam tylko publicznych właściwości z prywatnym setterem. Seter tworzy w tle pole prywatne.

Dlatego mój stary klasyczny styl programowania był:

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;
 }
}

W zdecydowanej większości przypadków będzie to nazwa właściwości, do której uzyskasz dostęp, w przeciwieństwie do nazwy zmiennej (pole ) powodem tego jest to, że w.NET i w C# uważa się za dobrą praktykę w szczególności ochronę każdego fragmentu 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ą zdefiniować, ustawić i uzyskać accessory i robią takie rzeczy jak Walidacja, gdy manipulujesz tymi fragmentami danych.

Ale w innych przypadkach, takich jak Klasa matematyczna (Przestrzeń nazw systemu), istnieje kilka właściwości statycznych, które są wbudowane w klasę. jedną z nich jest stała matematyczna PI

Np. Matematyka.PI

A ponieważ PI jest fragmentem danych, który jest dobrze zdefiniowany, nie musimy mieć wielu kopii PI, zawsze będzie to ta sama wartość. Więc zmienne statyczne są czasami używane do współdzielenia danych między obiektami klasy, ale są również powszechnie używane do ciągłych informacji, gdzie potrzebujesz tylko jednej kopii fragmentu danych.

Dodatkowe informacje: Domyślnie Accesory get I set są tak samo dostępne jak sama właściwość. Możesz kontrolować/ograniczać dostępność dostępu indywidualnie (dla get I set), 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 set jest chroniony(bardziej ograniczony dostęp).

Właściwości są używane do eksponowania pola. Używają accesorów (set, get), za pomocą których wartości prywatnych pól mogą być odczytywane, zapisywane lub manipulowane.

Właściwości nie określają miejsc przechowywania. Zamiast tego mają Accesory, które odczytują, zapisują lub obliczają ich wartości.

Używając właściwości możemy ustawić walidację na typie danych ustawianych w polu.

Na przykład mamy prywatne pole integer age, na którym powinniśmy dopuszczać wartości dodatnie, ponieważ wiek nie może być nie.

Możemy to zrobić na dwa sposoby używając getter i setter oraz używając właściwoś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()
       }
    }

Auto zaimplementowana właściwość jeśli nie mamy logiki w get I set accessors możemy użyć auto zaimplementowanej właściwości.

Gdy use automatycznie zaimplementowana właściwość compiles tworzy prywatne, anonimowe pole, do którego można uzyskać dostęp tylko za pomocą accesorów get I set.

public int Age{get;set;}

Właściwości Abstrakcyjne Klasa abstrakcyjna może mieć właściwość abstrakcyjną, która powinna być zaimplementowane 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ć nieruchomość W tym możemy prywatnie ustawić właściwość auto (set with in the class)

public int MyProperty
{
    get; private set;
}

Możesz osiągnąć to samo za pomocą tego kodu. W tej właściwości funkcja set nie jest dostępna, ponieważ musimy ustawić wartość bezpośrednio na pole.

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

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

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

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

Ludzie dostają się do sekcji dość łatwo, nie było żadnego sprawdzania

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 ze sobą coś złego