Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc

[adyre]

OOP or no OOP... that is the question....

Sunt genul de programator care nu s-a omorat cu OOP... tinand cont ca e tipic Java la ce bun in PHP? :P

E bine, am tinut sa ma bag sa invat si asa ceva... Sincer nici nu stiu cam ce vrea... functii inglobate intr-un singur loc.. k.. jale chestie.. nu ma intereseaza...

In schimb tot cautand am dat si peste http://www.webmasterstop.com/56.html Care mi-a concretizat credinta... se para ca OOP defapt ingreuneaza scriptul decat line by line sau functii.. bine, la functii nu cred ca am sa renunt ca sunt in mana.. parca singura scrie.... dar OOP cum nu prea m-am bagat... stiu cat sa citesc ceva.. dar nu prea vad rostul...

Acum vreau sa deschid acest topic tocmai pentru a vedea ce pareri contra si pro OOP exista.

Voi o sa ma convingeti daca da sau nu (poate si pe cei ce vor urma sa vada topicul acesta).

Chestionarul e valabil 30 de zile, asa ca grabiti-va!

[adyre]

Astept si pareri scrise, nu numai voturi!

[crivion]

s-a mai discutat de n ori , dar nici eu nu ii vad avantajul !

[Weedkid]

nici eu nu m-am omorat cu OOP, nu il folosesc decat cand scriu aplicatii mari, pentru ca poate nu lucrez singur la ea, si o sa aiba nevoie de update-uri. la aplicatii mici sunt devotat functiilor.. astfel imi termin treaba mai repede, decat sa imi prind urechiile, sa ma enervez, sa iasa o ciorba mare de tot pentru nimica toata

e frumos sa vezi intr-o aplicatie mai maricica, un main.php format frumos cu obiecte, decat o turma de functii aruncate

probabil ca in php6 o sa se puna mai mult accentul pe oop

[adyre]

Sorry... eu doar vreau sa cercetez "piata" din prezent :D

[UnD3aD]

inainte trebuie sa stii ce inseamna OOP si dupa sa il folosesti...

Citat: tinand cont ca e tipic Java la ce bun in PHP

tipic java? :)

Citat: se para ca OOP defapt ingreuneaza scriptul decat line by line sau functii..
se pare...

Citat: functii inglobate intr-un singur loc..
atat stii tu despre oop se pare...

//edit
ala care a facut testu ala e un idiot... n-are nici o legatura cu folosirea oop in aplicatii

[adyre]

Nush, mi se pare destul de realist...

Sorry pentru graba (pentru pere, mere... :P )... Da, cam atat stiu (nu e nevoie sa bag vreo scuza).

PS: "Utilizarea OOP
O abordare importanta a activitatii de programare, care a devenit populara in anii '90. ..... limbaj precum Java care este in mod intrinsec oreintat spre obiecte...

Mah, cam atat am inteles eu.

Oricum, te rog comenteaza de ce anume ti se pare mai buna OOP.

PS: incearca cu un script de page load time
Cod:
<?php
$timp = microtime();
$timp = explode(" ", $timp);
$timp = $timp[1] + $timp[0];
$start = $timp;

//OOP, FUNCTIE sau NORMAL

$timp = microtime();
$timp = explode(" ", $time);
$timp = $timp[1] + $timp[0];
$sfarsit = $timp;
$diferenta = ($sfarsit - $start);
print "Pagina s-a incarcat in ".$diferenta." secunde!";
?>

Baga in db si fa 5 refreshuri pentru fiecare varianta, apoi fa o medie... Mi-e mi-a iesit cam nasol cu OOP (bine, diferenta foarte mica, dar toturis diferenta...)...

Acum asteptam si varianta ta :D

[Amenthes]

In primul rand, eu am votat pentru.

In al doilea rand... UnD3aD, imi pare rau sa pun asta, dar postul tau nu zice nimic. E total nefolositor pentru persoane care vor sa invete ceva. Ar fi mult mai constructiv daca ai face un monolog in loc sa pui intrebari retorice.

Bun, si acum sa vad ce s-a lipit de mine din toata programarea asta.

OOP-ul este, simplu, o metoda de refolosire a codului (code reuse). Ca si functiile de altfel. Alte caracterisitici ale OOP, specifice OOP si de altfel amintite si prin alte posturi prin forumul asta, caracteristici de manual chiar, sunt:

- incapsulare
- mostenire
- polimorfism

Astea 3 sunt avantajele majore ale OOP in comparatie cu PP (programare procedurala). E adevarat insa ca avantajele incepi sa le vezi la proiecte mai mari si nu la un site de 2-3 pagini, desi si aici ai putea avea nevoie de o clasa de email pentru un formular de contact.
Acum, nu prea e bine sa confunzi clasele cu Programarea Orientata Obiect. Toata lumea stie sau ar trebui sa faca o clasa in PHP, macar in PHP4. Asta nu inseamna insa ca stie OOP. OOP inseamna sa stii cum sa relationezi clasele si aici intervin design patterns (sau sabloane de proiectare in romaneste, dar sincer, mie nu imi place sintagma). OOP trebuie gandit in asa fel incat daca mai tarziu ai nevoie sa schimbi ceva, sa schimbi intr-un singur loc, daca ai nevoie de functionalitate noua sa extinzi ceva sau pur si simplu doar sa creezi un fisier nou.

Exemplu: Am nevoie de redimensionarea unor poze, caz clasic, toti am avut nevoie. Acum, stim ca imaginile pe care le vrem redimensionate pot fi de mai multe tipuri, JPEG, GIF, PNG, BMP, WBMP. In stil PP ai face o functie destul de mare, cu un numar apreciabil de parametri si un switch in functie de cele cel putin 5 cazuri pe care le-am enumerat. Eu in OOP as face-o, de fapt am facut, asa: am o clasa de baza Image care imi va folosi mie ca portita pentru toate actiunile (a se citi metodele ) pe care vreau sa le fac. Si voi implementa si un pattern aici, strategy. Putin cod si explicatii dupa.

Cod:
<?php

class Image
{

    private $width;

    private $height;
   
    private $mime;
   
    private $size;
   
    private $type;
   
    // etc.

    /**
     *  variabila asta contine obiectul care va duce tot greul la ceea ce
     *  vreau eu sa obtin
     */
    private $strategy;

    public function __construct($image_path)
    {
        // Aici setez ca variabile private toata informatia pe care o pot
        // scoate din acea imagine cu getimagesize().
        //
        // Dupa ce am terminat cu variabilele private, aflu "strategia" pe care o
        // folosesc. Ce inseamna asta? In functie de mime type-ul imagini
        // incarcate in constructor voi include o clasa specifica.
        // Spre exemplu, daca mime-ul este image/jpeg voi include o clasa
        // Image_JPEG care va implementa o interfata iImage;
        // mai multe despre interfata mai tarziu.
        $this->_strategy = $this->_getStrategy();
    }

    private function _getStrategy()
    {
        // $this->type este prelucrat in constructor din mime type
        $strategy = 'Image_' . $this->_type;

        if ( file_exists($strategy . '.php') && is_readable($strategy . '.php') )
        {
            require $strategy . '.php';
            // De ce pasez constructorului strategiei obiectul care il instantiaza?
            // Ca sa am o cale de acces la variabilele private a clasei Image.
            // V-ati putea intreba de ce nu am o clasa abstracta Image pe care sa o
            // extind cu clase in functie de mine. Raspunsul e nu vreau sa ma
            // intereseze de mine type. Eu am sa scriu in cod:
            //
            //  $image = new Image('imagine.jpg');
            //  $image->resize( parametrii );
            //
            //  nu ma priveste ce face clasa inauntru. Asta e incapsulare sau
            //  alta sintagma este black box programming.
            return  new $strategy($this);
        }
        throw new Image_Exception('Image type not supported, file not found or file unreadable');
    }

    /**
     *  Metoda asta pare sa nu faca nimic nu?
     */
    private function resize($width, $height)
    {
        $this->strategy->resize($width, $height);
    }

}

?>


Si acum o clasa strategie care va fi folosita de clasa Image:

Cod:
<?php

class Image_JPEG implements iImage
{

    /**
     *  Va fi obiectul care a initializat aceasta clasa;
     *  Prin intermediul ei pot afla ce date vreau despre imagine
     *  pastrand prelucrarea lor doar in clasa Image
     */
    private $caller;

    public function __construct($caller)
    {
        $this->caller = $caller;
    }


    public function resize($width, $height)
    {
        // latimea pozei
        $this->caller->width;
        // inaltimea pozei
        $this->caller->height;
       
        // redimesionarea propriu-zisa a poze cu imagecopyresampled spre exemplu
    }

}

?>


Acum, ceea ce am facut eu a fost polimorfism si incapsulare. Polimorfism pentru ca e clar ca Image poate prelucra mai mult "forme" de imagine, iar incapsulare pentru ca eu nu stiu ce face clasa inauntru ca sa isi dea seama ce si cum sa prelucreze. De ce am implementat o strategie pentru clasele strategie... pentru ca am creat un mic sistem de plugin. Eu nu stiu sa fac o clasa strategie casa sa imi prelucreze PNG, dar poate stie X-ulescu, si atunci el creaza o clasa Image_PNG care implementeaza metodele definite in interfata iImage si gata. Nu mai trebuie sa modifice nimic in ceea ce am facut eu, clasa mea va cauta singua un fisier cu numele Image_PNG. Asta este switch-ul meu in stil OOP. E adevarat era frumos daca interfetele in PHP ne-ar fi lasat sa definim si tipul a ceea ce returneaza o metoda.
Clasele nu sunt bineinteles complete si le-am expus doar in scop exemplificator.

Asta e ce imi place mie la OOP, black box-ul si faptul ca il poti abstractiza foarte mult cu noile facilitati din PHP 5 (interfete, clase abstracte, class hinting, SPL). Hmm, poate ar trebui sa vorbesc si despre SPL (Standard PHP Library), e foarte interesant, pacat ca nu multi o folosesc sau stiu de ea).

Cateva lucruri nasoale in OOP, sa aduni functii fara nici o legatura intr-o clasa, sau... bucata de cod gasita in sursele unui programator de pe phpromania, foarte competent de altfel, dar nu stiu, a avut o mica scapare.

Cod:
<?php

class Location
{
   public static function Redirect($url)
   {
      return "
      <html>
      <head>
      <meta http-equiv=refresh content=\"0;url=$url\">
      </head>
      </html>";
   }
}

?>


Bun, hai ca am vorbit destul. Daca are careva intrebari sau critici (constructive) e perfect.

[adyre]

Omule, esti tare. Adica ai fost EXACT PE SUBIECT. Respect din partea mea pentru efortul depus. Adica totusi ai adus argumente clare si foarte utile.

Singura chestie e ca nu ai precizat ce parere ai de testul de pe adresa pusa de mine, restul numai bine. De-ar raspunde toti macar pe jumatate la cum ai raspuns u forumul ar avea o figura cam " :D " ci nu ":) "

Topicul ramane deschis la critici, insa u cam ai pus mus mult pe balanta pentru OOP.

[Amenthes]

Cineva a spus odata, nu mai stiu insa cine:

Citat: Optimization is the source of all evil

Hai sa incercam sa vedem ce poate OOP inainte sa spunem ca se misca greu.
O intrebare care o am eu, a facut cineva un benchmark intre cat de repede se modifica structura unei aplicatii scrisa procedural versus una scris OOP? Si nu e o intrebare chiar retorica, as vrea sa stiu ce diferenta ar fi. Sa nu se inteleaga ca am ceva cu functiile, sunt excelente pentru aplicatii mici. Eu unul recunosc ca deocamdata mai folosesc clase si pe unde n-ar trebui, doar ca sa inteleg mai bine cum sta treaba.

Adevarat, OOP e lent in comparatie cu celelelalte, dar lucrurile se vor schimba sigur, iar faptul ca invatam un limbaj in care OOP nu e asa avansat, sau nu era, ne da prilejul sa rumegam lucrurile usor si sa le intelegem mai bine iar pe viitor putem mai usor prinde Java, Python sau altele.
Sa vin totusi si cu o solutie pentru optimizare. Eu incerc sa evit pe cat posibil sa includ toate clasele necesare unei clase de baza inca de la inceputl fisierul. Incerc sa le incarc acolo unde stiu ca va fi nevoie de ele. Un exemplu in care nu se practica asa e Zend Framework. Acolo, ca sa scrii un cuvant intr-un document PDF iti incarca tot ce tine de PDF, clase de text, stil, imagine, stream, tot. Intrebarea e, ce nevoie am eu de clasa de imagine aici? Nici una... inca. Deci framewrok-ul ar putea fi putin regandit sau... facut un refactoring asupra lui ( http://www.refactoring.com/catalog/index.html ). La fel se intampla si cu Swift Mailer, unde iti incarca 15 fisiere sa iti arunce o exceptie. In CodeIgniter lucrurile sunt asa cum am zis eu, de fapt de acolo am invatat chestia asta. Ce nu inteleg eu la multi e de ce incearca sa aplice TOATE tehnicile din Java in PHP. Java e de obicei compilat, chiar si in varianta pentru web pe cand PHP e compilat de fiecare data cand e executat, mai putin daca ai un opcode cache. Asa ceva chiar cred ca sterge diferentele dintre PP si OOP.

Ah, mersi de aprecieri, ce nesimtit am fost

[adyre]

K. Aici as putea sa te contrazic putin deoarece important e ca site-ul sa ruleze repede, nu sa dai mura-n gura altuia sau sa iti ia 2 ore in loc de o zi intreaga sa modifici ceva ca aici poti argumenta ca poate nu o sa modifici chiar atat de des site-ul.

Cat despre opcode din cate stiu e ceva separat ce trebuie instalat, nu ma adancesc in subiect pentru ca nu prea stiu, dar din cate am inteles nu prea multe hosting-uri are asa ceva, si e cu dus - intors (citisem fugitiv intr-un articol).

Faza ca nu inteleg cu pledezi Java-PHP... eu stiu ca in Java fara OOP nu se poate programa, iar faptul ca e compilat deja face ca rularea lui sa nu fie diferetiata de utilizarea OOP sau nu (daca ar fi fost posibil, ca daca as zice ca e ma-as cam contrazice, si nu numai pe mine).

Oricum u m-ai convins ca trebuie sa trec si prin asa ceva si sa ma informez indeaproape despre OOP. Totusi observ (asta am intepretat eu) ca utilizarea OOP de cineva fara experienta prea multa e mai mult negativa decat pozitiva si ca proiectarea trebuie realizata logic pentru a nu face uz.

Pe la finalul acelui text scrie si ceva de genul:
Citat:
Therefore, the next time you are developing PHP code, you should consider whether you want faster execution times / less CPU load, or easier to maintain code.

Intr-un final nu pot spune decat multumesc Amenthes (si nu numai) pentru interventia de calitate si astept in continuare pareri PRO si CONTRA. Consider ca este un subiect destul de "piperat" in domeniu.

[Pirahna]

Ok, sa fim seriosi, la ce calculatoare personale si servere sunt in ziua de azi, si un cod care merge incet se misca foarte repede.

Eu consider ca folosind OOP iti organizezi mai bine dracia.
Daca vrei sa lucrezi cu alt programator sau chiar cu o echipa ... OOP este foarte necesar, ca sa separi functiile userilor de videos de muzica de functii de encriptare si de diverse alte chestii.

Pe langa asta, cum zicea si cineva mai sus, poate fi refolosit.
Adica ai o clasa care face nu stiu ce, cand ai nevoie intr-un proiect doar iei clasa, ii dai drumu si ti-ai rezolvat problema.

La php nu prea conteaza daca ai 500 de linii sau doar 100 in fisier ... conteaza ce output ai. Ala trebuie optimizat ca ala e practic tot ce tranferi intre server si client.

Nu am nici o parere contra, si mi-am expus argumentele pro. Mai sunt cateva gen cod curat etc etc, dar asta se poate aranja si la non-OOP.

[UnD3aD]

Amenthes:
Citat: Un exemplu in care nu se practica asa e Zend Framework.

faptul ca le incarca nu e o problema prea mare... important e sa nu creeze obiecte care nu le foloseste... ceea ce nu face...
oricum daca folosesti __autoload poti sa scoti require-urile alea...
zf e un exemplu de cod 100% OOP si cu toate avantajele care le aduce acest stil de programare

dupa ce intelegi OOP si il folosesti... te indragostesti de el :)

[huleacatalin]

As veni cu o completare, pe care nu am gasit-o pana acum in acest topic. Parerea mea este ca esenta OOP este ca iti permite sa aplici in programare exact sintaxa gramaticala pe care o folosesti in realitate, si asta iti da arhitectura aplicatiei, care iti permite dupa aceea sa extinzi sau sa modifici aplicatia 100% corect, si cu o putere pe care programarea procedurala nu ti-o ofera. Exemplu concret, te intalnesti cu clientul si notezi discutia pe o foaie, iar el ti-a spus (sa zicem in cazul unui magazin online):

"Vreau un site unde sa am User de tip Admin pentru interfata de administrare. Pe siteul public vor fi Useri de doua tipuri: Persoane Fizice si Persoane Juridice care se logheaza() folosind _username_ si _password_. Adminul poate sa adauge() din administrare Categorii si Produse in acele Categorii. Produsele trebuie sa aiba _descriere_ si _pret_. Userul poate sa adauge Produsele in cos, iar apoi sa trimita Comanda; Comanda poate sa contina mai multe LiniiDeComanda, care reprezinta fiecare Produs comandat, intr-o anumita cantitate. Comanda are un _status_ pe care Adminul poate sa il schimbe()".

Asta inteleg eu ca se numeste un "user story" (dar si eu sunt inca in faza de a invata lucrurile astea, astept sa fiu corectat daca nu e asa). In acest user story - adica ce vrea clientul de la tine, am scris cu litere mari clasele care compun arhitectura siteului tau (gramatical, urmaresti substantivele importante din propozitie). Am scris cu underscore (ex. _descriere_ si _pret_) proprietatile obiectelor - gramatical, atributele acelor substantive de mai sus. Si am pus paranteze la verbele referitoare la obiecte - astea vor fii metodele claselor, cum ar fi "se logheaza()".

Daca te duci apoi si scrii aceste clase intr-un director, sa zicem numit "logic" - de la "business logic", fiecare in propriul fisier, practic ai grupat intr-un singur loc toata povestea intregului tau site. Dar trebuie sa scoti de acolo HTML-ul si SQL-ul si sa scrii cat mai putin cod. Apoi, cand vine un alt programator, este de ajuns pentru el sa citeasca ce e in directorul "logic", unde este foarte putin cod, si foarte ordonat, iar intr-o jumatate de zi va intelege tot ce face siteul tau, chit ca este unul mare de tot, pentru ca aici sta esenta a ceea ce vrea clientul de la tine - care este businessul lui.

Si dupa ce a rasfoit si a inteles directorul "logic", poate sa se duca pe site unde stau HTML-urile sau SQL-urile, si Slava Domnului oricine stie sa citeasca un SQL sau un HTML. Dar el deja stie acum ce trebuie sa faca siteul, care sunt cerintele lui. Deci daca era procedural, el stia programare PHP, dar ca sa inteleaga proiectul trebuia sa citeasca o tona de cod sau o tona de documentatii ca sa poata lucra fara sa strice.

Dar, daca scrii OOP, noul programator stie PHP dinainte, iar ceea ce nu stie despre proiect invata mult mai repede deoarece e concentrat totul intr-un singur loc.

[huleacatalin]

La final, iese ceva de genul... Comparatie:

Pagina scrisa procedural:

Cod:
<?php
$q = "select * from products
     where title like '%" . mysql_real_escape_string(@$_POST["title"]) . "%'
     and manufacturer like '%" . mysql_real_escape_string(@$_POST["manufacturer"]) . "%' ";
$res = mysql_query($q);
while($row = mysql_fetch_array($res))
{
    ?>
    <br><?php echo htmlspecialchars($row["title"]) ?>
    <?php
}
?>


Pagina scrisa OOP:
Cod:
<?php
$productsList = Product::getList(@$_GET["keywords"]);
for($i = 0; $i < count($productsList); $i++)
{
    $product = $productsList[$i];
    ?>
    <br><?php echo Escape::html($product->title); ?>
    <?php
}
?>



Cand te uiti prima data la pagina scrisa procedural, creierul tau intelege "cod php care afiseaza o lista de chestii in urma unui SQL care selecteaza ceva din baza de date... Hai sa citesc cu atentie si sa procesez SQL-ul ca sa inteleg ce se intampla".

Cand citesti codul OOP, creierul tau de programator pricepe din prima "A... uite, e ca o propozitie din lumea reala, doar ca formeaza un program in PHP: Ia lista de produse in functie de keywordurile introduse de user la tastatura si care vin din $_GET adica din address bar... Pentru fiecare produs din lista afiseaza-i titlul, dar ai grija sa faci escape la HTML sa nu se strice pagina".[/code][/quote]

[PHPRomania Bot]