Ktory jest prawidlowo zapisany:
- private int a {get;set;}
- public int a {get;set;}
Wydaje mi sie ze ten z public bo jak dam private to i tak z ta zmienna nie moge nic zrobic w sensie, ze nie moge ani jej pobrac ani nadac wartosci,mam racje czy nie ?
Ktory jest prawidlowo zapisany:
Wydaje mi sie ze ten z public bo jak dam private to i tak z ta zmienna nie moge nic zrobic w sensie, ze nie moge ani jej pobrac ani nadac wartosci,mam racje czy nie ?
getset napisał(a)
Ktory jest prawidlowo zapisany:
- private int a {get;set;}
- public int a {get;set;}
Żaden, bo nazwa właściwości powinna zaczynać się od wielkiej litery.
Wydaje mi sie ze ten z public bo jak dam private to i tak z ta zmienna nie moge nic zrobic w sensie, ze nie moge ani jej pobrac ani nadac wartosci,mam racje czy nie ?
Nie robi się raczej właściwości z akcesorem private
, bo właściwości służą do udostępniania na zewnątrz klasy, a to co jest private
możesz odczytywać i zapisywać tylko w ramach klasy. Za to nie raz tworzy się właściwości tylko do odczytu, tzn. z publicznym get i prywatnym set, wówczas to ma już sens.
- public int A {get; private set; }
No ale po co robic cos takiego jak mozna dac public int a; i mam to samo co z get; set; ?
somekind napisał(a)
Nie robi się raczej właściwości z akcesorem
private
, bo właściwości służą do udostępniania na zewnątrz klasy, a to co jestprivate
możesz odczytywać i zapisywać tylko w ramach klasy. Za to nie raz tworzy się właściwości tylko do odczytu, tzn. z publicznym get i prywatnym set, wówczas to ma już sens.
- public int A {get; private set; }
nie prawda :p - zdarzają się i prywatne właściwości - jeśli musisz coś zrobić w klasie po zmianie wartości zmiennej prywatnej to możesz albo napisać metodę do ustawiania tej zmiennej albo zamienić ją we właściwość
No ale po co robic cos takiego jak mozna dac public int a; i mam to samo co z get; set; ?
Kilka razy już pisałem na ten temat dłuższe posty, teraz tylko krótko:
int getA();
i void setA(int value);
funkcje takie tworzy się po to żeby użytkownicy byli zależni od interfejsu klasy a nie jej implementacji. Np. gdyby nagle okazało się że po zmienieniu A trzeba wykonać jakieś działanie to w przypadku właściwości to drobna zmiana, a przy publicznym polu jest to niemożliwe bez modyfikacji reszty kodu.Nie robi się raczej właściwości z akcesorem private, bo właściwości służą do udostępniania na zewnątrz klasy, a to co jest private możesz odczytywać i zapisywać tylko w ramach klasy.
Kod napisany przeze mnie trochę wcześniej dzisiaj
Direction to ogólny kierunek należący do zbioru { Left, Right, None }. Facing direction z reguły ma pokazywać etn sam kierunek, ale przy zatrzymaniu się (direction = None) pozostaje w ostatnim stanie. jak dla mnie całkiem elegancka prywatna właściwość
HDirection direction;
HDirection Direction
{
get { return direction; }
set
{
if (value != HDirection.None) { facingDirection = value; }
direction = value;
}
}
HDirection facingDirection;
"Raczej" to nie jest chyba jakieś skomplikowane słowo, wyraża jedynie mniejsze prawdopodobieństwo występowania jakiegoś faktu. ;P
@msm - szczerze mówiąc, nie wiem po co Ci ta właściwość. Równie dobrze mógłbyś mieć prywatną metodę ChangeDirection, a do odczytu używać pola, które i tak masz. Wyszłoby znacznie mniej kodu i chyba byłby jaśniejszy.
Prywatnych właściwości używałem w życiu chyba tylko w ASP.NETowych formach jako wrapperów na nietypowane słowniki ViewState czy Session.
Coś w tym rodzaju:
private int MyPrivateIntStoredInViewState
{
get { return this.ViewState["MPISIVS"] == null ? 0 : (int)this.ViewState["MPISIVS"]; }
set { this.ViewState["MPISIVS"] = value; }
}
Gdybym nie miał tej właściwości, to przy każdej potrzebie odczytania wartości z ViewState musiałbym wykonywać te operacje, więc ewidentnie widać DRY & KISS.
Dobra teraz ogolnie, get i set oprocz mozliwosci ustawiania i pobierania,umozliwiaja szybsza modyfikacje kodu jesli zachodzi taka potrzeba i nie musimy grzebac w kodzie a zmienic to w jednym miejscu i mamy z glowy,dobrze mowie ?
@getset - to prawda, ale jest pewna znacznie ważniejsza rzecz.
Jeśli napiszesz coś większego od HelloWorlda to będziesz musiał podzielić program jakoś sensownie na komponenty (np. do łączenia się z bazą danych / interfejsu użytkownika / przetwarzająca dane). Wtedy może się okazać że z jakiegoś powodu coś się zmienia w dostępie do danej w jednej z bibliotek. Jeśli w takim miejscu jest właściwość to OK bo zawsze można podmienić jej kod. Gorzej kiedy jest tam publiczne pole - wtedy trzeba przekompilować wszystkie biblioteki korzystające z tej jednej która się zmieniła. Jak bardzo szczęśliwi będą użytkownicy (musząc ściągać i update-ować kilkanaście bibliotek zamiast jednej) nie trzeba chyba mówić...
No wlasnie o tym mowie, podmianie tylko wlasciwosci,ok thx za odp.