Wątek przeniesiony 2014-09-01 15:34 z C# i .NET przez somekind.

Jaki cel mają properties w C#?

0

Jestem programistą C++, w międzyczasie przebiło się kilka projektów większych i mniejszych w Javie, ale w przeciwieństwie do C++ nie mogę o Javie powiedzieć żebym ją znał. W C# nie pisałem nic poza jakimiś zadaniami ze SPOJ itp. czyli generalnie języka nie znam w ogóle ponad poziom pisania w Javie/C++ z nadzieją że zadziała.
Do rzeczy, coś co mnie od jakiegoś czasu zastanawia. Co jest takiego... super w properties (właściwościach? nie wiem, czy to powinno się (tak) tłumaczyć) w C#. Dają one "przezroczystość" stosowania zmiennych prywatnych, ale... czy nie chodzi o to, żeby tej przezroczystości nie było? Czy nie po to pole jest prywatne, żeby... nie było do niego dostępu z zewnątrz? Zwykły getter, setter niejako gwarantuje "zastanowienie się" w momencie ustawiania jakiejś wartości.
Więc... po co?
Czytałem trochę na stacku, ale... bardziej skupiają się tam w czym lepsze są properies od publicznych pól, a mnie zastanawia to dlaczego to w ogóle istnieje.

0

Pole to tylko pole - bezpośrednio piszesz i/lub czytasz. W propertisach możesz zawrzeć dodatkową logikę do przekazywanych/odczytywanych wartości.

0

Zamiast tworzyć prywatną zmienną i do tego dwie metody (get i set), to wystarczy, że stworzyć properties:

public int Varriable { get; set; }

Zarówno get jak i set mogą mieć logikę.

dodanie znacznika <code class="csharp"> - furious programming

0

Zwykły getter, setter niejako gwarantuje "zastanowienie się" w momencie ustawiania jakiejś wartości.

To jest właśnie zamiast gettera i settera.

np:

class Rectangle
{
     public int A {get;set;}
     public int B {get;set;}
     public int Perimeter
    {
        get { return 2*(A+B);}
    }
}
0
dam1an napisał(a):

To jest właśnie zamiast gettera i settera.

Dobra, przypuśćmy, że załapałem, chociaż moim zdaniem nadal bezpieczniejsze i bardziej czytelne są zwykłe gettery settery, ale mniejsza z tym - ile osób tyle zdać, więc nie ma sensu w to dalej iść.

Jedno pytanie jeszcze tak na szybko - getter musi otrzymać swój typ? czy można mu przekazać coś innego i "obsłużyć"?

0

Nie, nie możesz mieć właściwości typu int i przekazać mu obiekt typu Car.

moim zdaniem nadal bezpieczniejsze i bardziej czytelne są zwykłe gettery settery

public int A {get;set;}

lub

private int a;

void SetA(int a)
{ 
    this.a = a;
}

int GetA()
{
    return a;
}

Serio, wolisz druga wersje?

0

A niby jakim cudem zwykłe gettery i settery sa bezpieczniejsze? O.o

0
someONE1 napisał(a):

A niby jakim cudem zwykłe gettery i settery sa bezpieczniejsze? O.o

Bo zapewniają, że nie zrobi się czegoś w stylu obiekt.pole = 10;
jednak napisanie obiekt.setPole(10) włącza myślenie, przynajmniej u mnie

dodanie znaczników `` - furious programming

0
dam1an napisał(a):

Nie, nie możesz mieć właściwości typu int i przekazać mu obiekt typu Car.

moim zdaniem nadal bezpieczniejsze i bardziej czytelne są zwykłe gettery settery

public int A {get;set;}

lub


private int a;

void SetA(int a)
{
this.a = a;
}

int GetA()
{
return a;
}


> 
> Serio, wolisz druga wersje?

Wolałbym pierwszą gdyby nie pozwalała na przezroczystość odwołań do zmiennej, tylko tworzyła automatycznie metody, przez które mam się odwoływać.
ale tak jak już pisałem, ile ludzi tyle opinii, więc pewnie milion osób woli takie rozwiązanie jakie jest
0

Nie odwołujesz się bezpośrednio do zmiennej. W takiej sytuacji public int A {get;set;} kompilator sam sobie przerabia kod na coś takiego:

private int a;
public int A 
{
    get {return a;}
    set {a = value;}
}

I samemu też w każdej chwili możesz przerobić właściwość jeśli w którymś momencie stwierdzisz że public int A {get;set;} nie wystarczy.

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