Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Implementacja klas
Forum PHP.pl > Forum > PHP > Object-oriented programming
kezard
Witam!

Załóżmy że mamy przykladowa funkcje doSomething() :

  1. function doSomething($obj)
  2. {
  3. $obj->imie = 'Adam';
  4. $obj->nazw = 'Kowalski';
  5.  
  6. return $obj;
  7. }
  8.  
  9. doSomething($test);
  10. echo $test->imie.' '.$test->nazw;


Ten kod oczywiscie zadziała, jednak pytanie brzmi czy warto implementowac klase dla obiektow wykorzystanych w przykladzie. Czy jest sens, nawet jesli zwracaja wiekszoa ilosc danych niz tylko imie i nazwisko? Czy warto tworzyc dodatkowy kod aby byc OOP czy nie marnowac czasu"skoro dziala" ? Jakie sa roznice techniczne?

Dla porownania :
  1. class Test
  2. {
  3. public $imie;
  4. public $nazw;
  5. }
  6.  
  7. function doSomething($obj)
  8. {
  9. $obj->imie = 'Adam';
  10. $obj->nazw = 'Kowalski';
  11.  
  12. return $obj;
  13. }
  14.  
  15. $test = new Test;
  16. doSomething($test);
  17. echo $test->imie.' '.$test->nazw
  18. ?>


Dodam że wykorzystuje to przy przekazywaniu danych do widokow (MVC). Czy warto tworzyc implementacje?

pozdrawiam.
wookieb
Nie
Crozin
Twoja klasa Test to bardziej coś na kształt struktur znanych chociażby z C, niż faktyczna klasa. W pewnych przypadkach takie coś mogłoby mieć zastosowanie, ale tutaj raczej nie.

Swoją drogą im szybciej wejdzie Ci w nawyk korzystanie z getterów/setterów tym lepiej.
kezard
Cytat
Swoją drogą im szybciej wejdzie Ci w nawyk korzystanie z getterów/setterów tym lepiej.


Dlaczego? Uwazam ze to marnowanie czasu na pisanie funkcji get i set tylko po to zeby przepisywac wartosci do zmiennych. Pozatym niepotrzebnie sie kod powieksza. Dlaczego nie upraszczac sobie bezposrednim dostepem do zmiennych?
marcio
Cytat(kezard @ 20.09.2010, 10:53:22 ) *
Swoją drogą im szybciej wejdzie Ci w nawyk korzystanie z getterów/setterów tym lepiej.


Dlaczego? Uwazam ze to marnowanie czasu na pisanie funkcji get i set tylko po to zeby przepisywac wartosci do zmiennych. Pozatym niepotrzebnie sie kod powieksza. Dlaczego nie upraszczac sobie bezposrednim dostepem do zmiennych?

Bo to sie mija z logika OOP?!?
kezard
Cytat(marcio @ 20.09.2010, 10:54:46 ) *
Bo to sie mija z logika OOP?!?


Czyli mam rozumiec ze jedynym arguementem jest "bo tak" ? Jak ktos tak wymyslil to tak to trzeba stosowac aaevil.gif ? Skoro ustawiam zmienne w klasie jako publiczne to po kij jeszcze bawic sie w set i get? Prosze o jakis argument smile.gif
NuLL
Hermatyzacja ? Polimorfizm ? Dziedziczenie ?

BTW - Twoj kod nie ma nic wspolnego z programowaniem obiektowym bo zamiast klasy mozna rowniez dobrze zastosowac tablice.
marcio
Cytat(NuLL @ 20.09.2010, 11:06:53 ) *
Hermatyzacja ? Polimorfizm ? Dziedziczenie ?

BTW - Twoj kod nie ma nic wspolnego z programowaniem obiektowym bo zamiast klasy mozna rowniez dobrze zastosowac tablice.

@NuLL myslalem ze @kezard sam do tego dojdzie ;] mylilem sie ;p

W php mamy malo "struktur" danych jako tako wiec albo robisz z klasy kontener ale nie w taki sposob tylko jakis bardziej wyrafinowany albo operujesz na array snitch.gif
NuLL
I dobrze ze PHP jest malo struktur bo one sa przeznaczone dla jezykow nieobiektowych tongue.gif
kezard
Cytat(marcio @ 20.09.2010, 11:11:20 ) *
@NuLL myslalem ze @kezard sam do tego dojdzie ;] mylilem sie ;p

W php mamy malo "struktur" danych jako tako wiec albo robisz z klasy kontener ale nie w taki sposob tylko jakis bardziej wyrafinowany albo operujesz na array snitch.gif



Widze ze sie nie zrozumilesmy, mialem na mysli ten konkretny przypadek klasy Test ktory podalem.

Cytat
BTW - Twoj kod nie ma nic wspolnego z programowaniem obiektowym bo zamiast klasy mozna rowniez dobrze zastosowac tablice.


W tej chwili tak to u mnie dziala na tablicach dlatego szukam bardziej obiektowego rozwiazania. Przykladowo model zwraca mi wyniki w postaci tablicy, kontroler ja obrabia i wysyla ja do widoku. Chcialem zastosowac jakas implemntacje tej struktury (przyklad klasa Test) ale odradziliscie. W tej chwili wyglada to tak ze mam w kodzie takie "kwiatki" :

  1. ....
  2. $finalList[$j]['arr'][$counter]['warehouse_out']
  3. $finalList[$j]['arr'][$counter]['warehouse_in_name']
  4. $finalList[$j]['arr'][$counter]['warehouse_out_name']
  5. $finalList[$j]['arr'][$counter]['estate_name']
  6. $finalList[$j]['arr'][$counter]['estate_id']
  7. $finalList[$j]['arr'][$counter]['ratios'][$r]['product_name']
  8. $finalList[$j]['arr'][$counter]['ratios'][$r]['lot']
  9. $finalList[$j]['arr'][$counter]['ratios'][$r]['value']
  10. $finalList[$j]['arr'][$counter]['ratios'][$r]['enoguh']


Co bardzo mi sie nie podoba a niemam pomyslu jak zamienic ten "twor" na bardziej przyjazny. Zamiana tego :

Cytat
$finalList[$j]['arr'][$counter]['warehouse_out']


Na to:
Cytat
$finalList[$j]->arr[$counter]->warehouse_out


Nie jest chyba rozwiazaniem ktorego szukam...
Cysiaczek
Po co chcesz to zmieniać? Jeśli nie zyskasz na tym nic, to nie ruszaj póki działa. Jeśli jednak przewidujesz jakiś rozwój, który potem może spowodować rozrost takiej tablicy to wtedy tak, warto coś z tym zrobić.
Crozin
Cytat
Dlaczego? Uwazam ze to marnowanie czasu na pisanie funkcji get i set tylko po to zeby przepisywac wartosci do zmiennych. Pozatym niepotrzebnie sie kod powieksza. Dlaczego nie upraszczac sobie bezposrednim dostepem do zmiennych?
Dzięki temu zyskujesz większą kontrolę nad dostępem do danych zawartych w obiekcie. Masz dodatkowy "punkt dostępu". Nawet jeżeli w tej chwili jest to tylko przypisanie/zwrócenie pola, w przyszłości może dość potrzeba rozbudowy tego (np. dodania jakieś walidacji danych). Co prawda w przypadku PHP takie gettery/settery to dodatkowe obciążenie, ale w praktyce jest ono zerowe, a elastyczność/przyszłościowość kodu na tym zyskuje.

Cytat
I dobrze ze PHP jest malo struktur bo one sa przeznaczone dla jezykow nieobiektowych
PHP to nie jest język obiektowy - nawet udawanie obiektowego słabo mu wychodzi. smile.gif

Cytat
W tej chwili wyglada to tak ze mam w kodzie takie "kwiatki" :
Wygląda mi na to, że używasz pętli for, zamiast foreach, która by prawdopodobnie uprościła zapis. Na początek możesz pokombinować w tę stronę.
smentek
Cytat
Dzięki temu zyskujesz większą kontrolę nad dostępem do danych zawartych w obiekcie. Masz dodatkowy "punkt dostępu". Nawet jeżeli w tej chwili jest to tylko przypisanie/zwrócenie pola, w przyszłości może dość potrzeba rozbudowy tego (np. dodania jakieś walidacji danych


Ale farmazony... Gettery i settery pisane same dla siebie są złe. Juz to przerabialismy a wy dalej swoje... ;(
Zyx
Farmazony? A ja myślałem, że to się "hermetyzacja" nazywa. Ponadto po co odkopujesz stare tematy?
mike
Cytat(Zyx @ 10.12.2010, 20:15:42 ) *
Farmazony? A ja myślałem, że to się "hermetyzacja" nazywa. Ponadto po co odkopujesz stare tematy?
Tyle tylko, że dołożenie do każdego pola automatycznie gettera to nie jest hermetyzacja. Hermetyzacja to ukrycie kodu a wystawianie kodu przez gettera to żadna hermetyzacja.
Zyx
Hermetyzacja to ukrycie wewnętrznej struktury klasy za interfejsem złożonym z metod, które mają kontrolować zmianę stanu każdego obiektu. Ponadto gdzie ja napisałem, by automatycznie dawać do wszystkiego? Dajesz tam, gdzie to jest potrzebne, implementujesz to tak, jak jest potrzebne, a getter/setter nawet nie musi mieć mapowania na pojedyncze pole. A że zazwyczaj ma? Nie zmienia to faktu, że to jest hermetyzacja, jako że ukryłeś wewnętrzną strukturę. Użytkownik nie musi wiedzieć, że to jest mapowane na pole prywatne/chronione.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.