Kiedy należy używać właściwości w c#?
0
0
Przyjęło się, że w klasie nie ma publicznych pól. Publiczne są tylko właściwości.
0
Przyjmowanie czegoś na wiarę(słowo dla ateistów), nie jest dobrym podejściem w programowaniu, znacznie lepiej wiedzieć dlaczego coś się robi, w szczególności jeśli jest to jeden z filarów programowania zorientowanego obiektowo[ czy jak to się tam tłumaczy na Polski (object-oriented programming)] :P
0
Nie za bardzo rozumiem pytanie. Jeśli się pytasz, czy używać właściwości, czy pól (zmiennych klasy), no to odpowiedź jest raczej oczywista. W programowaniu obiektowym nie posługujemy się polami. Tzn. nie udostępniamy ich na zewnątrz klasy. Może to być niebezpieczne, bo użytkownik klasy przypadkiem może zyskać kontrolę nad pewnymi elementami, nad którymi nie powinien ich mieć. Dlatego zasada jest taka, że wszystkie pola w klasie powinny być prywatne.
No dobra, ale jeśli mamy klasę Student, który ma pole imie, to jak się dobrać do tego imienia? No i tutaj wymyślono tzw. settery i gettery, czyli specjalne metody, które mogą ustawić wartość lub ją zwrócić:
public string GetImie()
{
return imie;
}
public void SetImie(string value)
{
imie = value;
}
Jasne, nie?
OK, no to mamy prywatne pola, settery i gettery. A co z tymi właściwościami?
Nie wiem, czy przed C# były właściwości w jakimś języku, więc dla uproszczenia załóżmy, że C# wprowadza coś takiego jak właściwości. Są to jakby właśnie te settery i gettery. No, ale po co używać właściwości, jak są już te settery i gettery? Odpowiedź jest prosta. Bo można. Poza tym to może nieco ułatwić pracę.
Tzn. zamiast pisać:
string imie = obj.GetImie();
obj.SetImie(imie);
możesz napisać:
string imie = obj.Imie;
obj.Imie = imie;
Zapis jest nieco krótszy. Ale tak naprawdę chodzi o pewne rozróżnienie. Metody używamy do wykonywania pewnych działań, np. dodanie studenta do bazy, zwiększenie wieku studenta o jeden rok (np. obj.ZwiekszWiek()) itd. A właściwości do przypisania jakiejś wartości, czyli np. wpisania studentowi wieku: obj.Wiek = 20;
Czyli metody wykonują jakieś operacje, a właściwości po prostu przypisują wartości atrybutom.
0
"Może to być niebezpieczne, bo użytkownik klasy przypadkiem może zyskać kontrolę nad pewnymi elementami, nad którymi nie powinien ich mieć"
jaki użytkownik, co miałeś na myśli?
0
jaki użytkownik, co miałeś na myśli?
Pewnie chodzi o kogoś kto używa danej klasy, tworzy jej instancje albo z niej dziedziczy.
0
Brunatny Rycerz napisał(a):
"Może to być niebezpieczne, bo użytkownik klasy przypadkiem może zyskać kontrolę nad pewnymi elementami, nad którymi nie powinien ich mieć"
jaki użytkownik, co miałeś na myśli?
Użytkownik klasy (czyli programista, który nie jest jej autorem) nie powinien mieć dostępu do składowych, których modyfikacja może doprowadzić do niespójnego stanu, albo nieprawidłowych zachowań.
Dobrym przykładem na przydatność enkapsulacji są obiekty Immutable. Są to obiekty których nie powinno się modyfikować po utworzeniu. W C# możesz wręcz uniemożliwić modyfikację przez nieumieszczanie setterów we właściwościach.
Innym przykładem są właściwości, których bezpośrednia modyfikacja nie ma sensu. Dla przykładu modyfikacja właściwości Length klasy System.String nie ma sensu i dlatego nie ma settera. Gdybyś przez nieuwagę miał jednak przypisanie do tej właściwości, to kompilator Ci tego zrobić nie pozwoli.
0
no dobrze, ale czy w prostych aplikacjach, które tworzy 1 osoba, np. w stylu choćby tego nieszczęsnego studenta, który będzie miał ~10 pól (prócz np. identyfikatora) czy też używać tych setterów? przecież 2 razy tyle pisania to jest :)
czy nie można używać public dla wartości które mogą się zmieniać, a dla tych które nie mogą wrzucić private z samym tylko get-em?
0
Jesli jestes poczatkujacym programista to nie uzywaj nigdy fieldow - wyrob sobie nawyk (taka konwencja jest w c#). Jak jestes doswiadczonym to rob jak tam chcesz ale ze wzgledu na nawyki bedziesz uzywal propertiesow a nie fieldow. Co do tego ze jest 2x wiecej pisania to nie zupelnie - piszesz prop i tyle - reszte za Ciebie robi VS.
0
to teraz pytanie beginera.
czym różni się
public int x {get;set;}
od
private int y{get;set;}
jak rozumiem, pisząc {get;set;} przy kompilacji i tak jest tworzone pole prywatne dla x.
co w drugim przypadku...
0
Czym rózni się public od private: https://msdn.microsoft.com/pl-pl/library/ms173121.aspx
Używanie prywatnych set/get//stackoverflow.com/questions/3310186/are-there-any-reasons-to-use-private-properties-in-c
0
Brunatny Rycerz napisał(a):
to teraz pytanie beginera.
czym różni się
public int x {get;set;}
od
private int y{get;set;}jak rozumiem, pisząc {get;set;} przy kompilacji i tak jest tworzone pole prywatne dla x.
co w drugim przypadku...
W drugim przypadku też utworzone zostanie prywatne pole dla y, z tym, że sama właściwość również jest prywatna.
Właściwości to tak naprawdę dwie metody. Właściwość o nazwie MyProperty {get; set}, to tak naprawdę dwie meteody get_MyProperty i set_MyProperty. Dlatego właśnie dla właściwości automatycznych tworzone jest dodatkowo pole.
0
Będe używał skrótu myślowego wlasciowosc ustawiajaca wartosc/odczytujaca wartosc <-> seter/geter.
Wolałem zaznaczyć żeby nie było... o jej, o jej :)
Dam 2 proste przykłady bo one chyba dobrze trafiają do młodych (w sensie doświadczenia ;) ) programistów.
Właściwość możne dobrze ukryć implementacje. Np termometr.
Możesz mieć 3 właściwości (ustawiajace i odczytujace) C F i K a tak naprawdę temperaturę trzyma obiekt ...
w jakiejś dziwnej skali np Newtona bo w niej najczęściej są jakieś obliczenia.
Czyli hermetyzujemy implementacje a dajemy odpowiednio przygotowany "interfejs" w formie właściwościowi / metod.
Zawsze należy choć chwile się zastanowić: czy ten get będzie potrzebny? czy ten set bedzie potrzebny i czy użycie "gołego" seta nie spowoduje fail'a ;)
Dużym błędem jest automatyczne generowanie seta i geta z...przyzwyczajenia / z automatu.
Często samodzielne użycie (niezabezpieczonego "gołego") seta prowadzi do katastrofy.
Przykład: Mamy sobie kwadrat.
Powiedzmy ze wewnętrzna implementacja to 4 wierzchołki (wiem wiem przesada, ale to przykład).
Zamiast metody ustawiającej (i sprawdzającej) 4 wierzchołki mamy samotne sety.
I co? programista w nawale pracy zmienia jeden wierzchołek.
Tu wychodzi 2-gie zastosowanie metod dostępowych: zlecając ustawienie można ładnie "dopisać sprawdzanie".
Np w pewnym momencie (nie wiesz o tym na początku) dochodzisz do wniosku ze jakaś zmienna nie może być ustawiona w określony stan.
Mając metodę dostępowa łatwiej nanieść zmiany niż z wykorzystaniem pola na "chama"
Pozdrawiam,
0
Juhas napisał(a):
Nie wiem, czy przed C# były właściwości w jakimś języku, więc dla uproszczenia załóżmy, że C# wprowadza coś takiego jak właściwości.
Nie, no jak to nie wiem? A Delphi to co? ;)