akcesory - czy stosować i dlaczego

Odpowiedz Nowy wątek
2011-07-12 18:39
getset
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 ?

na przyszłość twórz bardziej sensowne tematy wątków, bo polecą do kosza. ten nie poleciał tam tylko dlatego, że zawiera wartościowe odpowiedzi. - ŁF 2011-07-13 13:14

Pozostało 580 znaków

2011-07-12 19:30
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; } 

Pozostało 580 znaków

2011-07-12 20:35
getset
0

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

Pozostało 580 znaków

2011-07-12 20:59
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ść


- Ciemna druga strona jest.
- Nie marudź Yoda, tylko jedz tego tosta.
Google NIE GRYZIE!
Pomogłem - kliknij
raczej != nigdy, ubezpieczyłem się od takich wyjątków ;) - somekind 2011-07-12 23:14

Pozostało 580 znaków

2011-07-12 22:05
msm
1

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;

Pozostało 580 znaków

2011-07-12 23:40
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.

Bo chciałem podać przykład 'sprzed chwili', też jakoś nie jestem specjalnie przekonany do tej właściwości :(. Aczkolwiek ty też możesz się poprawić bo twój getter można przepisać na this.ViewState["MPISIVS"] ?? 0; :P - msm 2011-07-13 00:18
Cannot implicitly convert type 'object' to 'int'. An explicit conversion exists (are you missing a cast?) - somekind 2011-07-13 00:35

Pozostało 580 znaków

2011-07-13 00:09
getset
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 ?

Pozostało 580 znaków

2011-07-13 00:25
msm
0

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

Pozostało 580 znaków

2011-07-13 00:27
getset
0

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

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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