ďťż

Programowanie obiektowe PHP - czy opłaca sie tak programowac?

Podstrony

telcocafe

Tak jak w temacie czy oplaca sie programowac obiektowo w PHP? Czy pozniej sie to przydaje przy tworzeniu innych skryptów? Nigdy nie programowałem obiektowo w żadnym jezyku i własnie nie wiem czy zaczynac przepisywac kody PHP. PHP umie dosyc dobrze . Co wy o tym sądzicie
Użytkownik root edytował ten post 22 październik 2006, 08:34

Warto, kod jest ładniejszy i czystszy.
Wygodniej się programuje, ma się większą kontrolę nad zachowaniem skryptu.

Poza tym, imho warto znać każdy język i sposób programowania (nawet takie jak cobol ^^), a jak mówisz że nigdy nie używałeś OOP - zacznij. Niekoniecznie się przerzuć na to, ale poznaj, wtedy sam ocenisz - warto czy nie (jak dla Ciebie) .

IMHO warto - klasy tworzy sie intuicyjnie, a i potem w przyszlych projektach mozna z nich korzystac bez jakichkowleik poprawek. Nalezy jednak pamietac, ze obiekt to nie moze byc tylko zbior funkcji - tak czesto zaczyna sie tworzyc klasy (sam przez to przeszedlem :] )

Przeczytaj książkę "PHP5. Obiekty, Wzorce, Narzędzia". Po tej lekturze będziesz wiedział kiedy obiektowość Ci się przyda a kiedy nie*.
OOP można się nauczyć, ale nie trzeba zawsze używać. Wystarczy wiedzieć, że coś takiego istnieje i jak tego używać, bo być może przyda Ci się to w którymś z projektów.

* Przeważnie dość często ;).

Przywracam temat, aby nie tworzyć nowego. Przedstawię tu swoje rozważania na temat projektowania obiektowego a strukturalnego.

Nie rozumiem, dlaczego dla wielu koderów programowanie strukturalne to zaniżaniem poziomu. Istnieją popularne i wydajne projekty napisane strukturalnie (osCommerce, PhpMyAdmin). O różnicach i zastosowaniach OOP <-> procedury można pisać w nieskończoność. Na razie nie znalazłem przekonywających argumentów za OOP. Poświęcę jednak chwilę czasu i skomentuję niektóre fakty a zarazem mity. Jeśli jest potrzeba, można przenieść dyskusję do innego tematu. WAŻNE: Podczas rozmowy możemy wymieniać się argumentami i przedstawiać zalety oraz wady tych rozwiązań, przy czym nie przezywamy się epitetami.

Samo PDO nie ułatwia budowy skryptu

Biblioteka udostępnia użyteczne metody napisane w C. Nie musimy pisać funkcji od podstaw. Wszystkie metody i zmienne są tak samo nazwane i można ich użyć dla każdego silnika bazy danych. W czym więc problem? W tym, że odwołując się bezpośrednio do metod PDO, piszemy więcej kodu. Dla twórców wtyczek może być to dodatkowe utrudnienie.

Przykład - pobranie danych:
$arts = $db -> query('SELECT ... FROM ' . $prefix .'arts ...'); Możemy zażądać zapisania wszystkiego w tablicy lub użyć WHILE. while($row = $stmt -> fetch()) { ... } $arts->fetchAll(PDO::FETCH_COLUMN, 0);

To nie koniec - jeszcze trzeba zwolnić wynik, a w przypadku MySQL użyć unset($arts), ponieważ występują problemy.

Inny sposób. Wyciągnięcie 1 rekordu:
$art = db_read('pola', 'nazwatabeli', ' WHERE...');

Albo zapis do globalnej tablicy dwuwymiarowej:
db_read('ID,name...', 'arts', ' WHERE...', 'zmienna', 'ta');

Prawda, że szybciej i łatwiej? Rozwiązanie ma też wady, bo przed zapisaniem do tablicy dwuwymiarowej musi nastąpić policzenie ilości rekordów (inaczej funkcja zapisze 1 pusty rekord). Zapis następuje bezpośrednio:
$GLOBALS[$var] = mysql_fetch_array($result);

W tym wypadku lepiej połączyć te funkcje z PDO, czy dopisać odpowiednie metody (jeśli to możliwe)?

2. Programowanie strukturalne - dlaczego tak?

Jeśli potrzebujemy interpretować BBCode, dołączamy bibliotekę (np. inc/bbcode.php) i wywołujemy odpowiadającą za to funkcje. Nie ładujemy do pamięci zbędnych funkcji lub metod, których nie używamy na danej podstronie. Nie ma ograniczenia (np. tylko dla nowości albo tylko dla komentarzy). Chcemy uzyskać login autora, gdy mamy jego ID - wywołujemy funkcję Autor($id) - użycie zmiennej globalnej $user w środku nie jest złem. Przecież chcemy mieć globalny dostęp do danych użytkowników - chyba że kod jest w całości zorientowany obiektowo.

Każdy plik zawiera zbiór poleceń PHP wraz z instrukcjami warunkowymi i komentarzami, a także wcięciami. Kod więc jest przejrzysty. W OOP również można się zagmatwać. Dla ułatwienia zbiór funkcji można również poprzedzić przedrostkami (np. db_).

Kolejną sprawą jest ograniczenie ilości funkcji, które często są zbędne. W celu zapisu danych do pliku utworzyłem funkcję Zapisz() z 4 argumentami. Po pewnym czasie uznałem, że niepotrzebnie ładuje się do pamięci za każdym razem. Zapis do pliku pojawia się tylko kilka razy w CMS-ie, a wywołanie funkcji fopen(), flock(), fwrite() i fclose() nie sprawia dużego kłopotu.

W CMS-ie istnieją również biblioteki / pliki współdzielone, które wykonują określoną akcję od razu po ich dołączeniu na podstawie istniejących danych, np. zapis plików konfiguracyjnych na podstawie danych $_POST, cache menu (pobiera dane z bazy i pakuje do plików w postaci kodu HTML i gotowych funkcji).

3. Moduły, rozszerzalność, użycie w innych skryptach

Część wyjaśniłem wcześniej. Spotykam się ze stwierdzeniem, że w przeciwieństwie do kodu strukturalnego, kod napisany obiektowo można wykorzystać w innych skryptach. Wg mnie to mity. Po pierwsze zarówno niezależne funkcje jak i metody klas mogą mieć różne lub takie same nazwy. Nie praktykowałem OOP w projektach PHP. Zwolennicy mają częściowo rację - mowa tu np. o systemach szablonów (każdy szablon jest obiektem) bądź różnych silnikach, interfejsach (niech będzie nawet bazodanowych). Łatwość edycji i tworzenia dodatków zależy od dokumentacji skryptu.

4. Kiedy używać OOP?

Wniosek: kiedy naprawdę potrzeba i rzeczywiście ułatwia tworzenie elementów skryptu.

Kod zorientowany strukturalnie i kod zorientowany obiektowo (tzn. opiera się całkowicie na obiektach) to 2 odmienne metody (wybór między Equites Imperiatoris a Equites Caesaris). Wsparcie i grono fanów zależy raczej od popularności projektu.

Czy zgadzacie się z powyższymi argumentami, czy jest inaczej, niż napisałem? Pamiętajcie, że powyższy tekst odnosi się do projektowania logiki skryptu. Co innego w programach, które są uruchomione przez dłuższy czas, a ich elementy (np. przyciski, formularz, lista wyboru) są obiektami i posiadają odmienne właściwości oraz zdarzenia. :) Podobnie w Javascript, gdzie wszystko jest obiektowe. Przykład zastosowania własnych funkcji jako klas:
obiekt = new Edytor('abc'); <input ... onclick="obiekt.bbcode=1" /> <input ... onclick="obiekt.Format('text','bold')" />Jest akcja -> jest i reakcja :)
Użytkownik Ferrari edytował ten post 04 czerwiec 2007, 18:48

Przywracam temat, aby nie tworzyć nowego. Przedstawię tu swoje rozważania na temat projektowania obiektowego a strukturalnego.
http://forum.php.pl/...topic=69824&hl= Nie masz pojęcia o programowaniu obiektowym ani o tworzeniu profesjonalnych aplikacji www ani o optymalizacji z prawdziwego zdarzenia. Ci ludzie od dawna tworzą aplikacje w PHP za ciężką kasę i coś o tym wiedzą więc nie uważaj się za orła PHP bo nim nie jesteś.

Istnieją popularne i wydajne projekty napisane strukturalnie (osCommerce, PhpMyAdmin).
osCommerce - przestarzały kod, tragedia w modyfikacji, wymaga register globals na on ;) Czy widziałeś rozszerzenia do phpMyAdmin ?

Samo PDO nie ułatwia budowy skryptu
Ułatwia o tyle że jest jedno api do wszystkich baz danych. Jak stosuje się PDO to stosuje się zazwyczaj obiektowy framework

Jeśli potrzebujemy interpretować BBCode, dołączamy bibliotekę (np. inc/bbcode.php) i wywołujemy odpowiadającą za to funkcje
OOP nie wyklucza użycia funkcji (patrz CI i "helpers"), BBCode to też rola filtra szablonów (smarty)

użycie zmiennej globalnej $user w środku nie jest złem.
Jest. Tracisz hermetyzację - zmienne nie wiadomo skąd przenikają nie wiadomo gdzie. Argumenty funkcji i metod są po to by jasne było gdzie i jakie dane muszą przepłynąć. Używając globalnych zmiennych tracisz modułowość czy to obiektową czy strukturalną.

Część wyjaśniłem wcześniej. Spotykam się ze stwierdzeniem, że w przeciwieństwie do kodu strukturalnego, kod napisany obiektowo można wykorzystać w innych skryptach. Wg mnie to mity. Po pierwsze zarówno niezależne funkcje jak i metody klas mogą mieć różne lub takie same nazwy.
Istnieje coś takiego jak standardy programowania! Ja jakoś nie miałem problemów z wykorzystaniem różnych klas z phpclasses.org czy ich rozbudową, nigdy nie natrafiłem na kolizję nazw.

Nie praktykowałem OOP w projektach PHP.
To się NIE wypowiadaj o czymś o czym nie masz najmniejszego pojęcia

Ci ludzie od dawna tworzą aplikacje w PHP za ciężką kasę i coś o tym wiedzą Jak już pisałem, są różne metody tworzenia skryptów i różne przyzwyczajenia, a co najważniejsze - różne przeznaczenia. :)

wymaga register globals na on W PHP6 nie będzie już opcji register_globals jak i magic_quotes. Zdecydowanie popieram te decyzje.

Istnieje coś takiego jak standardy programowania! Ja jakoś nie miałem problemów z wykorzystaniem Chodzi mi o to, że zarówno klasy jak i funkcje w bibliotekach są przenośne.

Wystawiam na obserwacje skrypt forum PunBB. Obiektów używa wyłącznie do obsługi bazy danych - przynajmniej tyle zauważyłem. Bardziej widzi mi się wykorzystanie obiektów jako zapytań.
$query->addparam($_POST['name'], 'int');
PDO jest zbyt skomplikowane - może to odrażać początkujących (np. PDO::PARAM_STR).

Wracając do szybkiego odczytywania bazy danych za pomocą 1 polecenia, to lepiej wreszcie zastosować funkcję, która zwróci wskaźnik obiektu wyniku, czy dodatkową klasę? Pomyślę nad implementacją klasy do obsługi SQL'a.
Użytkownik Ferrari edytował ten post 04 czerwiec 2007, 21:20

Sitedesign by AltusUmbrae.

Darmowy hosting zapewnia PRV.PL