Wypowiedzi
-
-
Rafał Nowak:
Piotr Marian Gondek:
Rafał Nowak: Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.
Settery i gettery to są metody, które operują na polach, tak? Wiec nie operujemy bezpośrednio na publicznym polu. To, że zapis jest identyczny, to już inna bajka.
Ok, ale czasami to zwyczajnie wygodne i sensowne - np jeśli mamy klasę Klient, który ma imię i nazwisko, to jak proponujesz ustawianie danych osobowych tegoż klienta? setName, setSurname? Moim zdaniem istnieją elementy, które są właściwościami obiektu i do których dostęp jest czasem potrzebny. W takich wypadkach - używając PHP - moim zdaniem niepotrzebne jest pisanie metod, najlepiej zrobić te pola po prostu publiczne, a ewentualnie w razie potrzeby "zamaskować" je poprzez użycie __set i __get.
Mutator'y i accessor'y - tak, pola publiczne - nie. To moja opinia jako programisty, nie zmuszę Cię do niej ;)
Czasem, gdy potrzebuję stworzyć strukturę (której w PHP nie ma), to tworzę klasę z polami publicznymi. Jednak to specyficzny i rzadki przypadek.
BTW: moja wypowiedź porusza raczej temat lenistwa programisty. Szybciej jest napisać protected $name, niż stworzyć pole prywatne i mutator'a oraz accessor'a do niego, prawda? A to ciągnie za sobą konsekwencje, dlatego używanie pól prywatnych MOŻE BYĆ NIEBEZPIECZNE, a nie zakazane.
Ale dalej nie rozumiem na czym polega niebezpieczeństwo, chętnie się doedukuję :)
Java Podstawy, Wydanie VIII. Cay S. Horstmann, Gary Cornell; strona 221
-
-
Rafał Nowak:
Piotr Marian Gondek:
Nie używa się publicznych pól - hermetyzacja
E, nie zawsze to jest takie oczywiste - settery i gettery po prostu ułatwiają życie i są dobrą praktyką, ale generalnie różnica między $user->age a $user->getAge() jest dla mnie kosmetyczna i czasami (podkreślam!) powoduje więcej pisania bez specjalnego przyrostu elegancji. IMHO to kalka z Javy, która z kolei tę praktykę ściągnęła z C++, a w którym miało to duży sens, ponieważ nie istniały np. "magiczne" __set i __get, dzięki którymi możemy sobie w razie potrzeby stworzyć metody dostępu, ale w razie braku takiej potrzeby nie zaśmiecać sobie nimi kodu. Fajnie to ma Ruby zrobione, o ile dobrze rozumiem, można w nim w sposób przezroczysty "podmieniać" przypisanie na użycie settera (tak?).
Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.
Settery i gettery to są metody, które operują na polach, tak? Wiec nie operujemy bezpośrednio na publicznym polu. To, że zapis jest identyczny, to już inna bajka.
Należy uważać z chronionymi polami, ponieważ jeśli pole chronione jest referencją do obiektu, można nieświadomie w podklasie zmienić ten obiekt, a to łamie zasadę hermetyzacji.
?
Nie rozumiem na czym polega "nieświadoma zmiana obiektu" w podklasie. Skoro projektant klasy daje podklasom dostęp do prywatnej zmiennej to daje i już. Takie zmienne umożliwiają fajne rzeczy, np. w ORM w Kohana3 można zdefiniować reguły walidacji modelu w polu chronionym $_rules, dzięki czemu każdemu modelowi można nadać inne reguły przy posiadaniu jednej metody check() w rodzicu.Rafał Nowak edytował(a) ten post dnia 12.01.11 o godzinie 21:20
To akurat jest do wypowiedzi wyżej. @Michał nie czytał nigdzie o tym, że pola prywatne mogą być niebezpieczne. Ja to przeczytałem w 'Java Podstawy. Wydanie VIII'.
BTW: moja wypowiedź porusza raczej temat lenistwa programisty. Szybciej jest napisać protected $name, niż stworzyć pole prywatne i mutator'a oraz accessor'a do niego, prawda? A to ciągnie za sobą konsekwencje, dlatego używanie pól prywatnych MOŻE BYĆ NIEBEZPIECZNE, a nie zakazane.
-
Michał Wachowski:
Łukasz Karpuć:
W żadnym razie nie używaj publicznych atrybutów klas, unikaj chronionych.
Z czystej przekory, gdyż?
Jestem po prostu ciekaw uzasadnienia, bo jeszcze nigdy nie słyszałem ani nie wyczytałem przekonującego argumentu.Michał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 20:31
Nie używa się publicznych pól - hermetyzacja
Należy uważać z chronionymi polami, ponieważ jeśli pole chronione jest referencją do obiektu, można nieświadomie w podklasie zmienić ten obiekt, a to łamie zasadę hermetyzacji.
-
kleos.pl - Strona internetowa struktury MLM Zygmunta Czupryna, Lidera firmy FM Group Polska.
- 12.01.2011, 14:46
-
eRandkaWCiemno.pl - portal randkowy
- 12.01.2011, 14:45
-
bar-event.pl - redesign strony właściciela firmy Bar Event
- 12.01.2011, 14:45
