Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Istota programowania obiektowego
szajens
post 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:
  1. class Stefan {
  2.  
  3. public $ubranie;
  4. public $buty;
  5. public $czapka;
  6.  
  7. public function setUbranie($jakie) {
  8. $this->ubranie = $jakie;
  9. }
  10.  
  11. public function getUbranie() {
  12. return $this->ubranie;
  13. }
  14.  
  15. }
  16.  


i później wywołanie:
  1. $o->setUbranie('jensy');
  2. echo $o->getUbranie();


zamiast:
  1. $o->ubranie='dress';
  2. echo $o->ubranie;

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
Go to the top of the page
+Quote Post
Pyton_000
post 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.
Go to the top of the page
+Quote Post
szajens
post 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.
Go to the top of the page
+Quote Post
Pyton_000
post 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 wink.gif 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ą.
Go to the top of the page
+Quote Post
szajens
post 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 smile.gif
Go to the top of the page
+Quote Post
crafter
post 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
  1. class Stefan {
  2.  
  3. protected $ubranie;
  4. protected $buty;
  5. protected $czapka;
  6.  
  7. public function setUbranie($jakie) {
  8. $this->ubranie = $jakie;
  9. }
  10.  
  11. public function getUbranie() {
  12. return $this->ubranie;
  13. }
  14.  
  15. }

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
Go to the top of the page
+Quote Post
memory
post 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%)
-----


  1. class konto {
  2.  
  3. public$kasa= 0;
  4.  
  5. }
  6.  
  7. $konto = new $konto;
  8. $konto->kasa = 1200;
  9.  
  10. echo $konto->kasa;
  11.  


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 ? smile.gif

Ten post edytował memory 5.10.2015, 13:32:39
Go to the top of the page
+Quote Post
aniolekx
post 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
Go to the top of the page
+Quote Post
Spawnm
post 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 wink.gif
Go to the top of the page
+Quote Post
sazian
post 5.10.2015, 18:51:37
Post #10





Grupa: Zarejestrowani
Postów: 1 043
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=
Go to the top of the page
+Quote Post
szajens
post 5.10.2015, 19:55:27
Post #11





Grupa: Zarejestrowani
Postów: 150
Pomógł: 4
Dołączył: 3.01.2010

Ostrzeżenie: (0%)
-----


Cytat(sazian @ 5.10.2015, 19:51:37 ) *
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.
Go to the top of the page
+Quote Post
Crozin
post 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".
Go to the top of the page
+Quote Post
PrinceOfPersia
post 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ć
  1. $account->setMoney($account->getMoney() - 100)

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:
  1. $account->charge(100)

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


--------------------
Go to the top of the page
+Quote Post
viking
post 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
  1. public function setDate(DateTime $timestamp)


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).


--------------------
Go to the top of the page
+Quote Post
Crozin
post 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.

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ą).
Jak najbardziej tak - wszystko trzeba stosować "właściwie". smile.gif
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 28.03.2024 - 22:21