Istota programowania obiektowego |
Istota programowania obiektowego |
4.10.2015, 20:40:44
Post
#1
|
|
Grupa: Zarejestrowani Postów: 150 Pomógł: 4 Dołączył: 3.01.2010 Ostrzeżenie: (0%) |
Przeglądałem kilkadziesiąt klas i zastanawiam się po co ludzie piszą na siłę dodatkowe metody np:
i później wywołanie:
zamiast:
mniej niepotrzebnego kodu a nadal jest bardzo czytelny edit: no i z klasy wypadają dwie niepotrzebne metody Ten post edytował szajens 4.10.2015, 20:41:38 |
|
|
4.10.2015, 20:54:36
Post
#2
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
To się nazywa Getter i Setter
Do tak trywialnego problemu oczywiście że bez sensu. Ale już przy bardziej złożonych problemach może być bardziej użyteczne, np. pobierając wartości zawsze robimy htmlspecialchars, dzięki temu zmieniamy w jednym miejscu a nie 1000 przy zapisywaniu lub odczytywaniu. |
|
|
4.10.2015, 21:06:23
Post
#3
|
|
Grupa: Zarejestrowani Postów: 150 Pomógł: 4 Dołączył: 3.01.2010 Ostrzeżenie: (0%) |
jak najbardziej w takich przypadkach(tych co ty podałeś) widzę sens, ale zauważyłem że ludzie nadużywają do takich prostych rzeczy jak ustawienie zmiennej masy metod, dla mnie to brak optymalizacji.
|
|
|
4.10.2015, 21:10:11
Post
#4
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
Zboczenie takie Jeśli nie ma konkretnej przesłanki aby używać ww. metod, to nie ma sensu stosowania.
W internecie jest wiele archeologii i bzdur które potem ludzie dublują. |
|
|
4.10.2015, 21:37:31
Post
#5
|
|
Grupa: Zarejestrowani Postów: 150 Pomógł: 4 Dołączył: 3.01.2010 Ostrzeżenie: (0%) |
Dzięki, bo już myślałem że ze mną coś jest nie tak
|
|
|
5.10.2015, 13:22:42
Post
#6
|
|
Grupa: Zarejestrowani Postów: 72 Pomógł: 2 Dołączył: 14.02.2007 Ostrzeżenie: (0%) |
jak napiszesz większą hierarchę klas wtedy zrozumiesz:D
akurat w tym przykładzie nie ma to sensu ale już w tym poniższym jak najbardziej
a dlaczego bo nie zawsze chcemy aby zmienne składowe klasy były dostępne zewnątrz, chodzi tu głównie o kontrolę aplikacji. Ten post edytował crafter 5.10.2015, 13:24:25 |
|
|
5.10.2015, 13:32:03
Post
#7
|
|
Grupa: Zarejestrowani Postów: 616 Pomógł: 84 Dołączył: 29.11.2006 Skąd: bełchatów Ostrzeżenie: (0%) |
Teraz wyobraź sobie młodego programistę który przez przypadek zamiast porównać $konto->kasa == 100 daje $konto->kasa = 100 Ile będziesz miał na koncie ? Ten post edytował memory 5.10.2015, 13:32:39 |
|
|
5.10.2015, 13:33:05
Post
#8
|
|
Grupa: Zarejestrowani Postów: 340 Pomógł: 46 Dołączył: 31.07.2009 Skąd: A Ostrzeżenie: (0%) |
sprawdz co sie kryje pod: Hermetyzacja (enkapsulacja, ang. encapsulation)
Ten post edytował aniolekx 5.10.2015, 14:39:54 |
|
|
5.10.2015, 13:34:41
Post
#9
|
|
Grupa: Moderatorzy Postów: 4 069 Pomógł: 497 Dołączył: 11.05.2007 Skąd: Warszawa |
Hermetyzacja zapewnia że jak za kilka miesięcy pojawi się potrzeba dodania ficzeru to wystarczy zmodyfikować getFoo zamiast połowę kodu itd
|
|
|
5.10.2015, 18:51:37
Post
#10
|
|
Grupa: Zarejestrowani Postów: 1 045 Pomógł: 141 Dołączył: 19.09.2006 Skąd: B-tów Ostrzeżenie: (0%) |
ma to jeszcze jedna zaletę, "zawsze jest tak samo".
Kiedyś zacząłem się "uczyć biblioteki" wxwidgets(to taka biblioteka do c++). Po kilku godzinach miałem już dosyć, w tej bibliotece część opcji jest(była ?) przekazywanych jako parametry, a cześć przez getery i setery. I weź tu teraz człowieku zastanawiaj się co chwilę i sprawdzaj w dokumentacji czy może szerokość to mam przekazać jako setWidth czy może width= |
|
|
5.10.2015, 19:55:27
Post
#11
|
|
Grupa: Zarejestrowani Postów: 150 Pomógł: 4 Dołączył: 3.01.2010 Ostrzeżenie: (0%) |
ma to jeszcze jedna zaletę, "zawsze jest tak samo". Kiedyś zacząłem się "uczyć biblioteki" wxwidgets(to taka biblioteka do c++). Po kilku godzinach miałem już dosyć, w tej bibliotece część opcji jest(była ?) przekazywanych jako parametry, a cześć przez getery i setery. I weź tu teraz człowieku zastanawiaj się co chwilę i sprawdzaj w dokumentacji czy może szerokość to mam przekazać jako setWidth czy może width= Powiem Tobie przyjacielu że mnie przekonałeś. To jest jeden konkretny powód dla którego warto dokładać kod, tracąc na optymalizacji. |
|
|
6.10.2015, 07:22:56
Post
#12
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
1. Nie przejmuj się mikroskopijnymi stratami wydajności - nie są warte uwagi tutaj w przeciwieństwie do dobrej jakości samego kodu.
2. Settery umożliwiają jakąkolwiek kontrolę nad tym co się dzieje i co jest przekazywane w kodzie. Tak, są nieco monotonne w pisaniu, ale pierwsze lepsze IDE załatwi to za Ciebie. 3. Kod staje się zdecydowanie mniej wrażliwy na zmiany. Wewnętrzny stan obiektu nie jest udostępniony bezpośrednio zewnętrznemu "użytkownikowi". |
|
|
6.10.2015, 14:24:08
Post
#13
|
|
Grupa: Zarejestrowani Postów: 717 Pomógł: 120 Dołączył: 18.04.2009 Ostrzeżenie: (0%) |
Cytat("Crozin") 3. Kod staje się zdecydowanie mniej wrażliwy na zmiany. Wewnętrzny stan obiektu nie jest udostępniony bezpośrednio zewnętrznemu "użytkownikowi". No ale jeśli mamy gettery i settery, to z jednak definicji wewnętrzny stan obiektu jest udostępniany zewnętrznemu użytkownikowi (tyle, że pośrednio, jedyna różnica), i użytkownik może odczytać albo zmienić stan obiektu w dowolnym momencie. I to niebezpiecznie łamie zasadę enkapsulacji. Dlatego trzeba to robić z rozsądkiem, są sytuacje gdzie gettery i settery są użyteczne, ale stosowanie ich na oślep bo komuś się wydaje, że na tym polega programowanie obiektowe (co jest kompletną bzdurą). Zamiast setterów/getterów setUbranie (pomijając już, że pisanie zmiennych pół po polsku, pół po angielsku nie ma sensu), można np.: - zlikwidować potrzebę odwołania się do zmiennych obiektu. Np. załózmy, że mamy konto bankowe. Wtedy jeśli chcemy komuś odjąć kasę z konta, wtedy zamiast pisać
co jest dość brzydkie (i również podatne na pomyłki nie bardziej niż twój przykład, @memory, wystarczy, że komuś się plus z minusem pomyli), możemy zrobić metodę charge:
wtedy obiekt sam będzie wiedział, co zrobić z tymi pieniędzmi. Jednocześnie zlikwidujemy potrzebę odwoływania się do wewnętrznego stanu obiektu. - można jeszcze zlikwidować w ogóle stan obiektu i pozwolić na ustawianie ubrania tylko przy inicjalizacji obiektu (a później dany obiekt byłby po prostu niezmienialny). Wtedy jeśli byśmy chcieli zmienić ubranie to po prostu tworzylibyśmy nowy obiekt klasy Stefan, który by miał skopiowane z poprzedniego właściwości, oprócz ubrania, które byśmy ustawili inne. Ten post edytował PrinceOfPersia 6.10.2015, 14:27:58 -------------------- |
|
|
6.10.2015, 18:05:41
Post
#14
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 Dołączył: 30.08.2006 Ostrzeżenie: (0%) |
Setterami możesz też wymuszać konkretny typ danych
Od 7 również typy podstawowe oraz zwracany typ danych. Świetnie sprawdzają się również z hydratorami (automatyczne transormacje między np danymi z bazy a encjami w aplikacji). -------------------- |
|
|
6.10.2015, 18:31:32
Post
#15
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat No ale jeśli mamy gettery i settery, to z jednak definicji wewnętrzny stan obiektu jest udostępniany zewnętrznemu użytkownikowi (tyle, że pośrednio, jedyna różnica), i użytkownik może odczytać albo zmienić stan obiektu w dowolnym momencie. I to niebezpiecznie łamie zasadę enkapsulacji. Jak najbardziej tak - wszystko trzeba stosować "właściwie".
Dlatego trzeba to robić z rozsądkiem, są sytuacje gdzie gettery i settery są użyteczne, ale stosowanie ich na oślep bo komuś się wydaje, że na tym polega programowanie obiektowe (co jest kompletną bzdurą). |
|
|
Wersja Lo-Fi | Aktualny czas: 27.04.2024 - 17:47 |