Jaki sens w stosowaniu akcesorów bez kodu?

0

Witam, ostatnio zastanowiłem się nad sensem stosowania takiego zapisu deklaracji pola klasy:

public int pole {get; set;}

Bardzo często takie coś jest spotykane, a ja nie widze w tym sensu. Sens widze, kiedy piszemy jakiś kod dla set i get, i np get zwraca jakąś wartość przeskalowaną, a set zabezpiecza, żeby nie ustawiać w kodzie np tej wartości na wartość poniżej zera. Ale takie coś? Mógłby ktoś się wypowiedzieć?

0

Bo później może zajść potrzeba aby jednak zwracało przeskalowaną wartość.

0

To nie jest pole tylko właściwość.

Więcej informacji tutaj: http://4programmers.net/Forum/Newbie/230290-do_czego_sluza_akcesory_w_c?p=1016389#id1016389

0
public int pole {get; set;}

„takie coś” jest w zasadzie równoważne temu:

public int pole;

— a jak zajdzie potrzeba, to i tak można to przerobić na właściwość…

Niektórzy reagują panicznym strachem, gdy widzą publiczne pole. Dla nich powstały akcesory domyślne {get; set;} by zamknąć im gęby :D

Sens, rzeczywiście, niewielki. Ale te parę znaków więcej nic nie kosztuje.

Czasami jednak trzeba użyć właściwości (choćby takiej trywialnej) — gdy korzystamy z refleksji, serializacji itp. wymagane są właściwości, nie pola.

0
Azarien napisał(a):

„takie coś” jest w zasadzie równoważne temu:

public int pole;

W zasadzie nie jest równoważne, bo wiele mechanizmów, które działają z właściwościami, z polami za bardzo nie zadziałają.
No, ale zawsze można udawać, że się wie więcej niż twórcy języka. ;)

— a jak zajdzie potrzeba, to i tak można to przerobić na właściwość…

I zrobić breaking change wymagającą przekompilowania (albo i zmiany kodu) wszystkich aplikacji korzystających z naszego kodu.

Pytanie - czy lepiej robić od razu porządnie, czy w przyszłości tracić czas na rozwiązywanie problemów, które się samemu sobie stworzyło jest zawsze aktualne.

3

Specjalistą nie jestem, ale chyba do pól np. z XAMLa nie można Bindować, muszą być to właściwości.

0

Ogolnie jest wiele bibliotek i frameworkow, w ktorych roznego rodzaje operacje czy tez mapowania rozrozniaja properties od fieldsow i najczesciej jest tak ze po prostu dla fieldsow pewnie rzeczy zwyczajnie nie dzialaja, gdyz nie mozna ich przeslonic jakas skomplikowana logika - sa to tylko "dumb" fields.
Najprostszy przyklad - obiekty proxy w EF przy lazy loading - musza byc propertiesy.

0
fdsfdsf napisał(a):

Najprostszy przyklad - obiekty proxy w EF przy lazy loading - musza byc propertiesy.

Bo pola są niewirtualne, więc nie da się ich nadpisać. W ogóle z polami nic nie można zrobić.

Skąd w ogóle pomysł, żeby używać pól jako interfejsu klasy? Bo właściwości jako właściwie metody, interfejs stanową same z siebie.

0

Uważam to za wadę języka: nie powinno być różnicy między polem a właściwością z domyślnymi akcesorami.
Niestety, nie pomyślano o tym od początku, domyślne akcesory doszły dopiero później.

Czyli takie coś:

int pole;

powinno oznaczać to samo co:

int pole { get; set; }

a pól powinno po prostu nie być.

albo inaczej rozumując: zmiana int pole; na int pole { get; set; } nie powinna wymagać rekompilacji modułów zależnych.

Ale tak nie jest.

0

@Azarien: ale to narodziłoby inne problemy, np. pola w strukturach.

0

Trudno mi sobie wyobrazić, jak zmiana pola na metodę miałaby nie powodować dużego zamieszania.

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