concepte si design OOP

Deja sunt tot mai incurcat.
Mai intai vreau sa imi explice cineva cum gandim in POO, cand folosim poo si la ce folosim poo.

Va rog eu, scoateti-ma la suprafata

Ruben56, on 23 iulie 2014 - 11:56, said:

OOP ar trebui sa folosesti peste tot intr-o aplicatie. Everything is an object.

Pentru OOP nu vei gasi definitii, il vei invata pe parcurs ce scrii cod. Eu iti
sugerez sa citesti o carte de designs patterns unde iti arata exemple practice
la probleme practice si vei vedea unde si cum se foloseste OOP-ul.

Apoi, in PHP am folosit un framework destul de ok care doar din documentatie
te impinge sa iti organizezi codul intr-o structura MVC, vei folosi
dependency injection pattern, service layer pattern, etc. Ti-l recomand, se
numeste Laravel.

Pac_Man, on 23 iulie 2014 - 10:25, said:

De ce nu e cel mai bun limbaj pentru OOP in mod special? Un singur
argument da-mi

@puya4ever Poate ai putea sa spui si numele unei astfel de carti, daca se poate!

niposs, on 23 iulie 2014 - 13:07, said:

In principiu oricare. Uite aici o lista:
http://www.fromdev.c...s-you-must.html

Ok, hai sa o luam cu inceputul.

In primul rand uita de design patterns la nivelul la care esti nu te vor ajuta cu nimic. Design patterns exista pentru cu totul altceva si in nici un caz pentru a te invata OOP. Pentru a le intelege trebuie deja sa stii si sa intelegi conceputul de OOP.

Bottom line: Ia o carte citeste si invata. Unde nu iti este clar vino, explica-ne ce nu intelegi si te vom ajuta.

Spor!

Invata teoria OOP si apoi incepe cu un framework de PHP, care te obliga sa gandesti OOP.

DominatoR, on 23 iulie 2014 - 13:52, said:

Sa vezi de cand caut eu sa invat aceasta teorie si numai balarii gasesc. Nimic nu m-a convins cum stau lucrurile.

Nu este cel mai bun limbaj pentru a invata OOP sau programare la modul general. In rest e un limbaj foarte bun pentru web, doar ca a avut o evolutie tumultoasa si nu e bun pt cineva care vrea sa invete programare pe bune.

De ce? Pentru ca e plin de inconsistente cu "jdemii" de moduri de a obtine acelasi lucru ba object-oriented, ba procedural cu decizii de design dubioase luate de-a lungul timpului.

Netul e plin de documentatie fie "outdated" fie direct proasta. Ce sa inteaga un incepator din asta? Mai combini si cu elementele arhitecturale ale web-ului si obtii o varza totala.

puya4ever, on 23 iulie 2014 - 13:03, said:

Stiu conceptele OOP dar nu stiu cum sa le aplic in PHP. Eu vreau un lucru practic.
Vreau sa stiu cand folosim oop... Folosim pentru fiecare chichineata? Mai exact la un register form. E mult mai simplu direct pe pagina sa verifici lungimea unui string decat sa il pasezi, etc.

Unii ziceau ca trebuie ca obiectul sa fie independent. Metodele nu trebuie sa aiba variabile externe. E adevarat?

Apai cu "unii ziceau" n-ajungi niciunde. Nu-ti mai pune problemele astea. Majoritatea zic tampenii.
OOP nu "folosesti". E un mod de a structura codul unei aplicatii. E vorba de arhitectura care garanteaza anumite lucruri pe care le doresti intr-o bucata mare de cod.
Tu trebuie sa intelegi care sunt lucrurile alea pe care le doresti: lizibilitate, mentenabilitate, separation of concerns, code boundaries (adica ce de ce depinde, cu ce si cum comunica), etc.
De lucrurile astea nu ai nevoie la nivelul tau. Ca sa le intelegi trebuie sa te lovesti de ele. O sa te lovesti de ele cand ajungi sa scrii aplicatii mai complexe pentru clienti "pe bune".
Deocamdata e OK sa incepi cu ce e aia o clasa si o instanta a unei clase, ce e un obiect, ce e incapsularea, modificatori de vizibilitate, etc. Adica chestiile pe care le inveti la o facultate de profil, sau dintr-o carte buna. Apropo, astea nu sunt chestii ce tin de OOP (exceptand incapsularea), ci, in anumite limbaje, sunt mecanismele prin care scrii cod OOP.

Mai scriu o data: poti scrie cod OOP si fara clase si poti scrie cod cu clase care n-are nimic cu OOP.

Edit
"Unii ziceau ca trebuie ca obiectul sa fie independent. Metodele nu trebuie sa aiba variabile externe. E adevarat?"
Da. E vorba de incapsulare si side effects. Metodele obiectului trebuie sa fie pure (google "pure functions"), adica primesc niste prametrii pe care nu au voie sa-i modifice si returneaza un rezultat. In procesul asta au voie sa faca orice in interiorul obiectului si nimic in afara lui (adica nu au voie sa modifice valorile parametrilor primiti prin referinta si nu au voie sa acceseze variabile globale).
E un principiu de baza despre care inveti in detaliu din orice carte buna.

Edit2
OK, trateaza validarea tot acolo. Maine te apuci de inca un formular in aceeasi aplicatie si ai nevoie de aceeasi validare. Copy-paste la cod si acolo. Pac, duplicate logic and code, a big no-no in OOP.
Lucrurile nu se fac dupa cum ti se pare tie mai usor sau mai frumos, ci dupa niste motive studiate si bine intemeiate. Nu vrei sa ai acelasi cod in doua locuri pentru ca peste un an nu o sa iti mai aduci aminte ca e in doua locuri. O sa-l modifici intr-unul singur si brusc ti-ai introdus un bug.

Ruben56, on 23 iulie 2014 - 14:30, said:

Nu sunt sigur ca intelegi acele concepte atata timp cat nu le poti pune in practica, dar hai sa facem un exercitiu.

Fa o aplicatie (web/desktop), de exemplu agenda telefonica, desigur structurand codul bazandu-te pe conceptele OOP.

Edited by just0rz, 23 July 2014 - 14:46.

Quote

cum?
daca n-ai clase n-ai nici obiecte

Si OOP-ul ce treaba are cu obiectele Javascript, Java sau PHP? Definitia unui obiect in OOP nu are nicio treaba cu definitia obiectului ca si construct al limbajelor de programare. OK, exagerez, se suprapun pe alocuri. OOP exista dinainte sa existe clase, obiecte si instante in limbaje. Incapsulare, vizibilitate, etc. sunt chestii ce le poti obtine si fara clase.

"OOP, defined in the purest sense, is implemented by sending messages to objects."
"An object can be considered a "thing" that can perform a set of activities. The set of activities that the object performs defines the object's behavior."
"Terminology invoking "objects" and "oriented" in the modern sense of object-oriented programming made its first appearance at MIT in the late 1950s and early 1960s. In the environment of the artificial intelligence group, as early as 1960, "object" could refer to identified items (LISP atoms) with properties (attributes)"

just0rz, on 23 iulie 2014 - 14:46, said:

Insfarsit cineva cu ceva practic. O sa incerc sa fac o agenda telefonica. Dar ma exact ce?
Sa poti adauga numere, sa poti sterge si sa vizualizezi numerele salvate. Presupun ca la asta e referi.

Edited by Ruben56, 23 July 2014 - 14:54.

Fa o agenda telefonica care sa aibe acelasi(simplist) comportament ca cea a telefonului tau.

Incep sa fac. Inca ceva vreau sa te intreb pe tine sergiu.
Ai zis si tu ca metodele trebuie sa fie cat mai independente si nu au ele voie sa modifice valorile primite.
Dar prin independenta asta nu am voie nici sa pasez valori direct la o metoda? Trebuie sa folosesc metoda accesor, sa le scriu in proprietati si dupa ma folosesc de metode fara variabile externe?

Pentru tema cu telefonul, am sa folosesc mysql pentru stocarea numerelor de telefon.

Te rog frumos sa boldezi in raspunsul tau deoarece e important ce ai zis, urmatoarea fraza:

Quote

vezi sa n-o dai in cealalta extrema.
am observat la php trendul a-la-symfony, adica sa creezi 3245345 de interfete si clase fiecare in fisierul propriu, pt orice chestiune minora. am vazut aplicatii banale structurate in 100 de clase doar de dragul "extensibilitatii" desi in viata reala nu s-ar ajunge in veci sa se faca uz de acest asa zis avantaj pt toate clasele alea

Foarte bine ai zis.
Deja incep sa inteleg mai multe cu ajutorul vostru si doresc sa discutam in continuare.

Deci tot "programul" trebuie gandit ca in viata reala, ce destinatie are si daca ma ajuta aceea clasa sau nu, nu doar sa fac clase de dragul poo, corect?