akcesory - czy stosować i dlaczego

0

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 ?

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

No ale po co robic cos takiego jak mozna dac public int a; i mam to samo co z get; set; ?

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

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ść

2

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 A {get; set;} to tak naprawdę cukier składniowy dla typowych dla np. C++ funkcji 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;
0

"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.

0

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 ?

1

@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ć...

0

No wlasnie o tym mowie, podmianie tylko wlasciwosci,ok thx za odp.

1 użytkowników online, w tym zalogowanych: 0, gości: 1