sam jestem noobem jesli chodzi o programowanie obiektowe ale rozumiem to tak. Jesli pole ma pelnic funkcje tylko zmiennej to daje to do public, jesli natomiast ma byc cos wiecej, np sprawdzenie wejscia albo cos dodkatkowego to uzywam do tego wlasnosci. Przykladem moze byc tekst dla jakies kontrolki. W delphi moze to byc np label1.caption i ta wlasnosc caption nie tylko przechowuje tekst ale robi tez rozne rzeczy jak np przerysowanie itp.
0
0
@mca64 czyli Twoim zdaniem np. w klasie kwadrat długość boku powinna być publiczna, bo jest tylko zmienną?
0
ja nie mowie jak powinno byc, bo ja tego nie rozumiem. Wiem ze te programowanie obiektowe madrzi ludzie wymyslili wiec powinno sie stosowac ich regul a ze ja ich nie znam to i nie czuje tego to juz inna sprawa. Napisalem tylko jak na swoj rozum rozumiem te wlasnosci
a co do twojego przykladu to ja bym zrobil z tego wlasnosc, ze sprawdzeniem wejscia czy jest wieksze od 0
0
Ja rozumiałem to tak samo jak @mca64, ale skoro najbardziej kompetentny w tym zakresie człowiek jakiego "znam" (A. Troelsen) twierdzi inaczej, to mu zaufam ;-)
0
Tylko ludzi myślą, że w programowaniu obiektowym chodzi o klasy co jest bardzo różne od prawdy. W programowaniu obiektowym tak naprawdę chodzi o interfejsy. Ogólnie dobrze napisany kod obiektowy praktycznie nie będzie używał getterów i setterów poza sytuacjami jak modele czy repozytoria. W pozostałych przypadkach z reguły jest to naruszenie zasady podstawienia Liskov.
0
Wracając jeszcze do głównego pytania, dlaczego w c# properties a nie gettery i settery, chyba nikt nie wspomniał o zaletach Object Initializer. Przykład:
class Circle{
public int Radius {get; set;}
}
class CircleLand{
private List<Circle> circles = new List<Circle>();
public CircleLand(){
this.GenerateCircles();
}
public void GenerateCircles(){
for(int i=1; i<100; i++)
this.circles.Add(new Circle { Radius = i });
}
}
Oczywiście prosty przykład, ale do przeanalizowania jakby to musiało wyglądać z setterami.
0
Wystarczy stworzyć poprawny konstruktor?