Nimeni nu a adus nici un argument greu în favoarea OOP în PHP. Totul se bazează pe "amice, oh, încercați să înțelegeți cât de rece este"
Dacă creăm o aplicație GUI care funcționează în timp ce utilizatorul nu o oprește, atunci OOP este foarte recomandabil, cel puțin în timpul programării interfeței. Dar, în cazul PHP, programul rulează o fracțiune de secundă (în timp ce procesează cererea) și aceeași interfață nu ar trebui programată. Sarcini ale programului în PHP: să fie de înțeles, să fie rapid. Și ambele cazuri nu se referă la OOP.
Pentru a fi clar, programul are nevoie de o simplă logică prietenoasă (acesta este cel mai important nivel al abstractizării uitate), cod fără duplicate și documentație. Pentru a fi rapid, nu are nevoie de o sintaxă suplimentară.
Analizând același Laravel, văd câteva lucruri bune care sunt mai logice pentru a fi implementate în funcții și o grămadă de coduri de dragul codului.
Dar nu există nimic care să ne împiedice să scriem o funcție polimorfă în logică: q ():
Aceeași funcție poate primi SQL-interogare, sau mai complicate de proiectare-SQL, dar mai ușor de înțeles decât tehnicile de circuit. Cineva ar putea argumenta că funcția este legat într-o singură vizualizare bază de date, dar că ar trebui să vă reamintesc că, în funcție de tipul de bază nu este nimic nu interferează cu dreptul de a descărca fișierul cu punerea în aplicare corespunzătoare a funcției, de exemplu, mysql.db.php postgresql. db.php
Dacă logica codului procedural este echilibrată, dacă nu există cod duplicat, dacă există documentație, atunci codul procedural va fi mai bun decât orice alt cod OOP prin două criterii: accesibilitatea pentru înțelegere, viteza de lucru. Dat fiind faptul că codul OOP necesită, de asemenea, echilibrarea și documentarea, avantajele proceduralului devin absolute.
Și nimeni nu va aduce alte argumente. Nu există.
Tot ce poate fi implementat pe POR poate fi implementat fără ea. Undeva, OOP este convenabil. Dar mai des nu. Acest lucru este destul de logic, deoarece astfel este soarta oricărei paradigme, tehnologii sau instrumente. Chiar și un ciocan este convenabil numai pentru baterea cuie, iar pentru șuruburi șuruburile, șuruburile, piulițele și pereții shtrobleniya nu mai există. Acest lucru este logic.
Problema PLO este doar că oponenții săi încearcă să o evite, iar susținătorii săi o tulbat oriunde ar găsi.
Alexander Majugin.> Pot să vă găsesc, probabil, proiectele mele pe audiocaset. Oare el?
Da! Și există asemenea. ) Glumeam desigur.
> Problema PLO este doar aceea că adversarii ei ÎNTOTDEAUNA încearcă să o evite, iar susținătorii săi înconjurau-o în orice loc vor fi găsiți posibili.
Îmi place mai mult această opinie.
> Da! Și există asemenea. ) Glumeam desigur.
Uh-huh. Undeva trebuie să fie implementarea Sokoban pentru ZX-Spectrum. Adevărul este că există doar două imagini de prim nivel de care am găsit în revista. Și cum să-și genereze propria lor, atunci nu a venit.
Alexander Majugin. Nu spun că această programare procedurală este un panaceu. Ca răspuns, am citat cazuri în care este mai bine să folosiți POR ca o abordare. În special, dacă este implementată o aplicație personalizată (cu GUI etc.) Chiar și atunci când dezvoltați front-end pe javascript, este logic să vă bazați pe capabilitățile OOPshnye ale acestui limbaj de scripting.
În cazul PHP, sau chiar mai larg, în cazul procesării cererilor de limbajul interpretat de scripting pe partea de server, argumentele fundamentale folosesc PP mai mult decât OOP. Chiar dacă te uiți la Java și apoi în ea folosirea OOP este justificată, inclusiv faptul că aplicația web în sine lucrează în memorie tot timpul, fiind compilată.
Apropo, programarea procedurală este mai ușor de perceput de către consumatori, cei mai mulți dintre aceștia fiind dezvoltatori cu experiență mai mică decât media, sau chiar artiști de layout. Ar fi mai ușor pentru ei să înțeleagă codul procedural decât OOPShny, care este plin de regulile sale sintactice și, de cele mai multe ori, suge din conceptele degetului.
Alexander Majugin. Înțelegeți că, în cazul dvs., aceasta nu este o problemă cu OOP, nu? Această abordare, ca oricare altul, în mâini inept va crea doar probleme. Această utilizare eficientă eficientă necesită ani de practică și, eventual, zeci de ani. De asemenea, am văzut codul rău și chiar l-am scris. Dar am văzut un cod grozav. Am studiat OOP și tehnici moderne de programare pentru mai mult de trei ani și în prezent pot folosi doar o mică parte din capabilitățile sale. Pentru a folosi OOP la capacitate maximă, mă va lua cel puțin încă trei ani, cred. Dar potențialul și oportunitățile pe care le-am găsit când mă studiez sunt foarte impresionante.
Lucrez exact la fel ca și dvs. - cadrul dvs., totul este depanat etc. De câțiva ani, luptam în PLO, încercând să-mi dau seama unde să mă aplice. În cazul în care a aplicat, complexitatea a crescut dramatic.
Singurul loc în care POO părea logic pentru mine este clar și ușor de înțeles - dezvoltarea echipei sau dezvoltarea unui modul pentru un proiect gata pentru altcineva. În acest caz, îmi dau doar clasa sau setul de clase în spațiul meu de nume care rezolvă problema afacerii, oferind eventual un API.
Învățați corect să ridicați întrebări. În ceea ce privește internetul, această întrebare ar trebui să pară așa: În ce moment este timpul să renunțăm la utilizarea OOP?
Pentru a înțelege acest moment dificil, încercați să scrieți câteva site-uri despre cadrele OOP. Este posibil pe mai multe, și este posibil pe un singur lucru bun. Nu esența este importantă. La un moment dat, veți prinde această linie fină.
> dacă nu scrieți în stilul OOP - sunteți un ratat.
Acest lucru este deja depășit, acum modul de respingere a OOP! Uită-te la go - programare procedurală + interfețe.
Uită-te la Scala - abordări funcționale în ecosistemul Java (aici, de asemenea, Clojure și Kotlin).
În interfață există o singură funcție: ClojureScript, Elm, Purescript. Același modă acum este React + Redux.
Atât de îndrăzneț scorul de la OOP și de a începe să scrie pe Clojure + ClojureScript!
Șef de dezvoltare
Personal, am o înțelegere deplină a motivului pentru care OOP este necesar numai când am citit cartea "Codul perfect".
Citiți-o, este o carte pentru orice programator scris pe OOP și (dintr-o dată), fără. Există chiar și o astfel de secțiune: "Motivul rezonabil pentru utilizarea clasei", unde totul este bine mestecat. Cu exemple.
Dacă o rezolvi cu cartea lui Mat Zandrst, înțelegerea asta va fi și mai profundă.
Articole similare
Trimiteți-le prietenilor: