OOP PHP - Începător

Cum preferati sa fie fluxul?

user -> controller -> model -> view
sau
user -> controller -> model -> controller -> view

Tipul de aici sustine ca prima varianta e cea corecta desi exista frameworks in php folosind a doua varianta.

Sincer nu cred ca înțeleg la ce te referi, dar de obicei varianta mai simpla e mai buna

Pe scurt, tipul spune ca pattern-ul MVC corect e primul, cu fluxul intr-o singura directie (model-ul trimite direct catre view si nu intoarce catre controller), dar ca in PHP a fost inteles si implementat gresit, inclusiv in frameworks.

Intrebam pentru ca, in aplicatia tictactoe pe care vreau sa o fac sa stiu ce varianta sa urmez. Oricum, m-am razgandit, o fac simpla sa scap de ea, folosesc doar sesiuni.

Initial nu stiam de unde sa incep, acum am deja 4 variante din care sa aleg, doua ale mele, alte doua de pe net. Una (de pe net) e cool ca foloseste bitwise operations. Pretinde ca e foarte rapida. Varianta mea in schimb nu va avea iterari deloc si va folosi o matematica de clasa I cu incrementari. Cum am sectiune pentru teste, le pot face pe amandoua pe branch-uri diferite si sa testez care e mai rapida.

ai grija ca OOP-ul din PHP, sau mai bine zis din MVC si frameworkurile astea care au rasarit ca ciupercile dupa ploaie, este doar forma fara substanta.
lumea se chinuie sa faca uz de OOP pt ca "da bine" si nu pt ca ar avea nevoie / ar rezolva anumite probleme sau pt ca ar oferi niste avantaje reale.
este ca si cand vrei sa mergi la supermarket sa cumperi ceva, si in loc sa iei transportul in comun sau sa mergi cu bicicleta sau pe jos, faci scoala de soferi si iti cumperi masina SH ca asa ai auzit tu ca e mai comod. si apoi te mai si lasa masina pe parcurs.

acele asa-zise avantaje pe care tot le flutura unii, cu cod reuse, recycling, maintainance, encapsulation bla bla, NU se vad si in practica.
defapt e chiar contrariul. uita-te la orice aplicatie zend, laravel si ce mai vrei tu si o sa vezi ca tot codul e mai umflat, greu de urmarit si mentinut. in plus se misca mai greu din cauza ca sunt create tone de functii aiurea si phpul are overhead mare la apelarea functiilor, cel putin 5 si mai jos.

OOP-ul se foloseste atunci cand chiar te ajuta cu ceva, si nu la orice. iar cazurile in care ai nevoie de OOP sunt destul de rare.
vezi eternele exemple cu biblioteca si cartile.

Edited by alx42, 06 July 2018 - 10:28.

Pai e vorba de viteza/usurinta de dezvoltare vs performanta. Cand folosesti Zend sau Laravel aia faci, refolosesti cod. Nici mie nu imi surade ideea sa invat frameworks stufoase dar daca nu ai firma ta, faci ce ti se cere. Ma gandeam ca dupa ce construiesc ceva  mai calumea intr-un framework o sa-mi foloseasca la angajare. Si apoi, ce-o da Domnul

wolfenste, on 06 iulie 2018 - 10:44, said:

Nu mai filozofa atât, ai un issue deschis, rezolvă-l.

https://github.com/w...tactoe/issues/1

wolfenste, on 05 iulie 2018 - 14:15, said:

Indiferent cat timp clasele din model nu stiu/depind direct nici de cele din controller nici de cele din view.

O separare si mai faina e in cazul single-page applications unde in PHP (sau orice alt limbaj alegi pe backend) nu-ti mai pui problema afisarii datelor, esti mult mai concrentat pe logica aplicatiei, iar viewul e cu totul alt proiect ruland in browser/pe telefon/etc.

Edited by dani.user, 06 July 2018 - 18:27.

OriginalCopy, on 06 iulie 2018 - 14:19, said:

si e de trei zile ... nu l-am vazut

dani.user, on 06 iulie 2018 - 18:20, said:

adica spune-i ca ai dependency inversion intre layere

N-are treaba dependency inversion cu ce-am scris eu.

the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

|a spune-mi, daca am apliatia  A la un capat de lume care este viewul unei aplicatii B in alt capat de lume, care este interfata care le separa  ?

wolfenste, on 06 iulie 2018 - 19:13, said:

Lectia: ticket management

Se obisnuieste sa pui in mesajul de commit numarul ticketului pe care acel commit il rezolva. Asta ca principiu.

Daca faci acel mesaj de commit dupa cum vrea github, atunci github va inchide issue automat.

In orice caz, dupa ce rezolvi un ticket, ii schimbi statusul corespunzator - aici: closed/solved/whatever.

Daca vrei sa faci asta prin git in momentul git push, faci asa: https://help.github....using-keywords/

wolfenste, on 02 iulie 2018 - 19:54, said:

Lectia: test-driven development

E bine ca ai inclus teste, dar trebuie sa si integrezi testele in ciclul de dezvoltare.

Citeste despre test-driven development pe web.

In timp ce citesti descrierea documentului tau cu regulile jocului, scrie un test de integrare. Extrage din acel document substantive care ti se par relevante pentru domeniul aplicatiei (tictactoe) si foloseste-le ca nume de clase. Pentru fiecare clasa, extrage verbele relevante ca metode. Gandeste-te care ar fi parametri (daca ai nevoie) fiecarui apel.

Scrie testul/testele de ca si cum acel cod de productie ar exista deja, chiar daca el nu exista. Vei rula testul, care va esua, in mod logic, cu mesaje de eroare (de la phpunit, php, whatever).

Revino cu un commit cu testul, ca sa vedem cat de bine e designul, apoi ne bagam la implementare.

Ce spun printre randuri implica: cand scrii testul, faci deja si designul/arhitectura.

Te astept.

In mare stiam deja cum voi face odata ce m-am hotarat ce varianta de rezolvare a problemei sa urmez. Procedural nu cred ca ia mai mult de 30 - 60 min implementarea, plus timpul dedicat rezolvarii bug-urilor.
Ok, scopul nu e tictactoe ci deprinderea modului corect de lucru.

-plecat dupa TDD-
brb

Ok, scriu testul intai apoi codul ce trebuie sa treaca testul. Deci test, cod, refator, repeta ciclul.

Avem: unit testing, integration testing, functional testing si acceptance testing.

Integration testing se refera la a testa modul in care mai multe componente interactioneaza, in cazul meu clasele ce vor compune aplicatia tictactoe. Inteleg ca trebuie sa gandesc designul aplicatiei scriind testul ce va trebui trecut de aceste componente interactionand.

Dar pe wikipedia arata ca integration testing intra in scena dupa ce unit testing a avut loc cu succes.

"It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested"

sursa: https://en.wikipedia...gration_testing

E dupa preferinta fiecaruia pana la urma? Personal mi se pare corect intai design global apoi focus pe fiecare componenta, dar cere mai mult efort, imaginatie, experienta. Sunt doua chestiuni ce inca nu reusesc sa le leg:

* Integration testing se refera la modul in care componentele interactioneaza
* Dar cum sa interactioneze daca nu am scris nimic specific in ele? Adica, legatura dintre ele se afla in ele, nu? Iar despre continutul mai specific ar avea grija Unit testing.

Nu as ajunge sa scriu prea mult cod te testare ce nu are inca un cod ce il trece? Ca aici e problema, nu am idee cat de departe sa merg cu clasele astea (la cod de testare ma refer, stiu ca nu scriu inca nimic cod testabil). Daca le dau doar niste nume de clasa si gata sa zicem ca am designul dar unde e testul pentru interactiunea dintre ele, aka integration testing-ul? Nu vad padurea din cauza copacilor?

Scuze ca am scris prea mult. Am cautat dupa "integration testing programming" (nu ma imtereseaza sa fie cu php neaparat dar sa inceapa treaba cu integration, dar am gasit cu unit testing si se cam opreau acolo "tutorialele").

Edited by wolfenste, 13 July 2018 - 12:21.

LE: folosesc o abordare Top - Down cu test stubs?

Deci inainte de toate, trebuie sa fii constient de un lucru: cati programatori, atatea corpuri de idei legate de TDD (terminologie, mod de abordare, rolul testelor in ciclul de dezvoltare, structura lor, etc).

Eu iti voi spune o poveste simplificata, destul de simpla incat tu sa ii faci fata, dar destul de complicata incat sa aiba o oarecare consistenta.

Dupa ce prinzi spilul, iti poti rafina tehnica, cauta propriile preferinte, propriul stil, etc - dar dupa acest proiect. Deocamdata vei invata doar prin imitare, asa incat imaginea pe care ti-o faci sa fie macar un corp de idei coerent, nu o abrambureala completa.


Acum:

Arhitectura pe care o faci e concentrica. O numim "layered architecture", sau "onion architecture". In centru se afla business model. Mai la periferie se afla alte componente gen web, baza de date, etc.

Iti voi povesti doua scenarii, unul mai realist, unul mai simplificat.

A. Scenariu mai realist:

te asezi la o masa cu clientul, care iti spune povestea de business (iti descrie business model). Pe masura ce el povesteste, tu scrii niste teste. Cum se numesc aceste teste? Terminologia e foarte variata, dar noi le vom numi simplu doar "teste de integrare". In aceste teste, exersezi layerul din onion cel mai exterior.

Acel layer ar fi plug-in-ul web, dar noi am lasat la o parte acest plug-in pentru inceput pentru simplificare - ai destule alte probleme cu care te confrunti la acest nivel si nu vreau sa iti incarc studiul si sa te frustrez.

B. Scenariul simplificat:

facem un test de integrare, dar atacam in el direct "domain layer" din acel onion. E tot un test de integrare, dar la un nivel de nestedness mai in adancimea cepei, deci mai simplu: acopera mai putine componente.


Indiferent de nivelul la care ataci initial ceapa, scopul acestui test/acestor teste e sa iti mentina cursul, directia: stii ca o data ce acest test/teste sunt verzi, ai un deliverable. Aceste teste initiale de integrare sunt busola ta si vor fi rosii majoritatea timpului.


Cand rulezi aceste teste, una dintre primele erori va fi ca nu sunt gasite clasele. Deci primul cel mai la indemana lucru pe care il faci e sa creezi clase goale. Apoi rulezi iar aceste teste, si erorile vor fi ca nu sunt gasite metodele. Apoi creezi metode goale.

Apoi rulezi iar aceste teste initiale si ai o lista de erori, sau doar una, sau ce-o fi: e foarte situational. Iei din aceasta lista de erori una care corespunde unei zone din domeniu pe care vrei sa o implementezi, i.e. "drilling in". Cand sunt metode complexe, scrii un nou test pentru acele componente/layere aflate la si mai mare adancime, care te ajuta sa implementezi. Si tot asa, "drilling in", pana ajungi la unit tests.

Deci da, in acest sens, e o abordare top-down, atat cu testele, cat si cu implementarea, cu care mergi in tandem.

E ca la recursivitate: intri in adancimea structurii de date, rezolvi problema cea mai adanca, apoi la intoarcere din recursivitate combini solutiile partiale / piesele de puzzle pentru a rezolva problema mai mare, si tot asa, pana cand ai ajuns la nivelul de recursivitate 0, deci esti la testele initiale de integrare, pe care le rulezi si parca din magie ele devin verzi.



Proiectul e intentional extrem de mic (tictactoe) pentru ca tu sa poti face greseli fara a te durea prea mult: una e refactoring la 100 de linii de cod, alta la cateva mii, in caz ca ai gresit abordarea.

Vrei sa gresesti cat mai mult in acest proiect micut, pentru a gresit din ce in ce mai putin in alte proiecte mai realiste.

Inveti extrem de mult din greseli, deci da-i bice la gresit.


Nu stiu daca asta iti raspunde intrebarilor tale, dar tu baga tare acolo, incearca sa vezi ce iese, si inveti din mers.

Deasemenea, nu uita ca multe dintre ce iti zic sunt gandite pentru invatare, pe parcursul anilor o sa iti extinzi aptitudinile, intuitia, etc.

De exemplu, in situatia explicata mai sus in care ai o lista de erori si trebuie sa alegi una pentru "drilling in", pe care dintre ele o alegi poate fi uneori o arta, si intuitia necesara vine cu practica.

Reciteste asta:

Quote

Ce vei observa in practica e ca majoritatea timpului, dupa ce ai scris testele, nu trebuie sa gandesti aproape deloc, pentru ca mesajele de eroare iti spun practic ce trebuie sa faci, si sunt de obicei pasi mici si clari.

Daca nu sunt pasi mici si clari, atunci "drill-uiesti" cu o noua colectie de teste mai in adancime.


Deci presiunea cognitiva e in timp ce scrii testele, nu in timp ce scrii codul de productie. Codul de productie e doar un produs secundar al activitatii tale de a transforma teste din rosii in verzi.

PS: ce ti-am explicat in acest post e sumarul a catorva sute de pagini din diferite carti si multi ani de experienta. Deci: imita profesorul, greseste, evolueaza, depaseste profesorul.

wolfenste, on 13 iulie 2018 - 12:12, said:

Gandeste doar in termeni de unit testing si integration testing. Integration testing care ataca diferite layere din ceapa poarta diferite nume in functie de nivelul adancimii, intentia testului, care programator defineste terminologia, etc. Nu te obosi sa intelegi nimic dintre toate acestea, gandeste-te doar la integration testing si unit testing deocamdata.

Edited by OriginalCopy, 13 July 2018 - 16:21.

Nu am vrut sa par carcotas. Mergeam din articol in articol si peste tot gaseam (cel putin pana cand am editat) ca trebuie sa am unit testing gata cand ma apuc de integration testing. Eram putin frustrat ca nu gaseam ce trebuie si nu eram nici sigur ca 'integration' din cerinta e acelasi integration pe care il tot gaseam eu. Basca faptul ca multi incep o serie de articole si le lasa neterminate iar eu ma prind doar la sfarsit Ok, acum am gasit ca, culegerea substantivelor si a verbelor din documentatia mea s-ar numi object analysis si ar fi urmata de object oriented design. Stiu ca sunt chestiuni triviale dupa ce le fixezi si folosesti mai mult, dar aici ploua cu notiuni noi care mai cheama si rudele dupa ele.
I'll be back

Opreste-te din citit termeni, si scrie mai mult cod.

Nu intra in ceva analog cu "analysis paralysis", get things done instead.

Ai comentarii la ultimul tau commit, urmeaza-le. Vino apoi cu un test de integrare. E vorba de cateva linii de cod.

Scopul tau e sa gresesti cat mai mult, ca sa inveti cat mai mult.