Implementacja klas, Czy potrzebna? Opcje

[kezard]

Witam!

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

[PHP] pobierz, plaintext 
function doSomething($obj)
{
    $obj->imie   = 'Adam';
    $obj->nazw  = 'Kowalski';
 
   return $obj;
}
 
doSomething($test);
echo $test->imie.' '.$test->nazw;
[PHP] pobierz, plaintext 

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 :

[PHP] pobierz, plaintext 
class Test
{
	public $imie;
	public $nazw;
}
 
function doSomething($obj)
{
    $obj->imie   = 'Adam';
    $obj->nazw  = 'Kowalski';
 
   return $obj;
}
 
$test = new Test;
doSomething($test);
echo $test->imie.' '.$test->nazw
?>
[PHP] pobierz, plaintext 

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

pozdrawiam.

Ten post edytował kezard 20.09.2010, 08:29:50

[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]

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?

Ten post edytował kezard 20.09.2010, 09:56:18

[marcio]

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]

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 ? Skoro ustawiam zmienne w klasie jako publiczne to po kij jeszcze bawic sie w set i get? Prosze o jakis argument

[NuLL]

Hermatyzacja ? Polimorfizm ? Dziedziczenie ?

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

[marcio]

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

[NuLL]

I dobrze ze PHP jest malo struktur bo one sa przeznaczone dla jezykow nieobiektowych

[kezard]

@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

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

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" :

[PHP] pobierz, plaintext 
			....
                        $finalList[$j]['arr'][$counter]['warehouse_out']
			$finalList[$j]['arr'][$counter]['warehouse_in_name']
			$finalList[$j]['arr'][$counter]['warehouse_out_name'] 
			$finalList[$j]['arr'][$counter]['estate_name'] 
			$finalList[$j]['arr'][$counter]['estate_id']
			$finalList[$j]['arr'][$counter]['ratios'][$r]['product_name']
			$finalList[$j]['arr'][$counter]['ratios'][$r]['lot']
			$finalList[$j]['arr'][$counter]['ratios'][$r]['value'] 
			$finalList[$j]['arr'][$counter]['ratios'][$r]['enoguh']
[PHP] pobierz, plaintext 

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

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

Na to:

$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]

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.

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.

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]

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?

Ten post edytował Zyx 10.12.2010, 20:16:09

[mike]

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.