De ce am nevoie de oop

Dmitry. Probabil mi-am formulat greșit ideea. dar am înțeles acest lucru:

Aici am un CMS auto-scris. Aici am o grămadă de funcții, conținut de la baza colectării (tip de model), dar există o mulțime de funcții, conținutul care atrage pentru ieșire (tip de vedere).

Iată o versiune a prezentării finale, dar cealaltă. Modelul este la fel peste tot, iar punctul de vedere este parțial suprapus.

Mă gândeam ... bine, Cho, de ce nu o facem cu PLO? Am colectat toate modelele sub un singur acoperiș - a devenit grozav să le numim:
$ x = SampleModel () nou;
$ y = $ x-> prepareAuthorsList ();
$ v = nou TemplateXYZ (); (care este mostenit de la TemplateBase)
$ w = $ v-> showAuthors ($ y);

în mod clar, numele sunt complet arbitrare :)

nu "printAuthorsListFromDBforBootstrapTemplate (parametrul mullion)"

• *<>

Dar probabil acest lucru nu este încă un oop :)

Și apoi, în logica OOP nu este șters pe tot parcursul programului. Și două duzini de câmpuri localizate și 60 de metode din clasă îmbunătățesc perfect vizibilitatea. În programarea procedurală, componentele, desigur, nu sunt înlocuite fără dansează cu o tamburină.
Programele ciclo-OOP sunt copiate de la zero, la fel de des ca programele de bovine-proceduri. Programele bine scrise sunt citite și editate fără probleme atunci când folosiți oricare dintre paradigme.

Ca urmare, aplicarea principiilor POR vă permite să economisiți timp și efort de dezvoltatori. PLA nepermis (sau PPL din cauza lipsei de experiență) vă permite să trageți prin genunchi și citit-cap de 37 de ori.

Dintre orele minore ale cursurilor OOP sunt de obicei universale, ele ar trebui să funcționeze stabil pentru orice parametri valabili. Adesea, acest lucru are ca rezultat verificări multiple pentru aceleași condiții, probleme la deschiderea articolelor (uneori sunt închise de la buldozer, dar uneori sunt cu adevărat necesare), cerințe suplimentare (atunci când o clasă cu funcționalitate excesivă este utilizată pentru a rezolva problema). Toate acestea pot duce la pierderea vitezei.

În general, este ceva de gândit. Și există o mulțime de greble.

Voiam să vă întreb: ești student? Apoi a privit: nu, Webber. Webistii au nevoie foarte mult de POR foarte rar; dacă nu ați contactat suportul complicat al protocoalelor complexe sau al modelelor complexe de date - în memorie, nu în baza de date - puteți scrie fără OOP și fi un webist de succes.

Eu însumi nu am înțeles de mult pentru ce sunt aceste obiecte. Întrebarea principală: DE CE?

Pentru a transmite interacțiunea multor lucruri. În cazul în care nu există nici o interacțiune, nu există nici un POR și puteți efectua, de exemplu, calcule științifice, pe care puțini dintre noi sunt capabili să le acrobați, și, în general, nu știu despre PLO. Îmi amintesc cum Wasserman - același care a fost un inginer de proces - și-a amintit de mult timp ce este PLO.

Vă sugerez să începeți cu una simplă.

1. Sintaxa obiectului. A fost ...

A devenit mai frumoasă. Da, iar numărul câinelui poate fi transmis în mod aleatoriu, de exemplu, în loc de numărul de arme; cu tipul TMonster, acest truc nu va funcționa.

2. Encapsularea.
Ne gândim deja că apelurile pentru funcții nu pot aduce obiectul într-o stare "necorespunzătoare" și orice lucru pe care obiectul îl poate strica este blocat în privat.

3. Abstracție și moștenire. Aceasta este deja o "dificilă acrobație". Nu este cea mai înaltă - aceasta este o parte integrantă a abilităților unui programator bun, iar pentru 80% din sarcini nu este necesar, ci în restul de 20 și îmbunătățește foarte mult viața. Cel mai simplu exemplu. În unele jocuri 2D există un TGameObject cu funcții virtuale Live și Render. Primul scrolulează măsura "vieții" obiectului, al doilea îl trage pe ecran. TGameObject poate fi împărțit în TPlayer, TProjectile, TEnemy și TBonus, etc.

Da, da. Pentru OOP nu este nevoie de o sintaxă de limbaj și obiect orientată pe obiect, aveți nevoie de gândire orientată pe obiecte. De exemplu, Doom a fost scris în C, dar într-un stil foarte obiect.

prin simplitate și practică, de exemplu

1) trebuie să conectați cardul de plată la site
a) scrieți interacțiunea de la zero (scumpă și nu eficientă din punct de vedere al costurilor)
b) luați clasa gata, dacă aveți nevoie să moșteniți și să rescrieți câteva metode (mai rapide și mai fiabile)

2) să luați un fel de bibliotecă (sau chiar CMS), de exemplu, o biblie. IdiORM, codul de nucleu (kernel este clasele de bază) nu se schimbă, și moștenesc în clasa rescrie câteva metode utile de 5-10 ani codul proiectului dvs. nu devine caduc, deoarece nucleul poate fi actualizat fără a rupe proiectul, și toate școlile și vulnerabilitatea Timp de 10 ani veți fi eliminați prin actualizarea bibliotecii sau a cms-urilor

3) OPP vă permite să vă dezvoltați mai repede, de exemplu, pe baza bibliotecilor și a cadrelor gata făcute, inserarea înregistrărilor în tabele poate arăta astfel

Într-un stil funcțional, acest lucru nu este implementat

PS, din păcate, nu este tot ceea ce este implementat pe POR, implementat calitativ. Există exemple de abuz de POR și, dimpotrivă, complicând înțelegerea codului, dar acest lucru nu înseamnă că nu ar trebui să utilizați abordarea OOP.

Cele mai bune avantaje din limba C ++ sunt moștenirea și funcțiile virtuale.
În plus, membrii privați ai clasei sporesc fiabilitatea și protejează împotriva erorilor.
Cel mai rău lucru despre programarea C este utilizarea variabilelor globale. Nu știți unde se poate schimba și este prea greu să schimbați comportamentul programului. Și dacă schimbați variabila într-un singur loc (într-o clasă), atunci comportamentul clasei este foarte ușor modificat.

Și, desigur, este foarte convenabil când metodele de lucru cu un obiect (clasă) sunt stocate într-un singur loc.

În PHP, OOP este necesar atunci când mai multe funcții au nevoie de acces la variabilele comune.

Fără OOP ar fi necesar să se scrie un cod ca acesta:

Cu OOP, puteți scrie:

Fără OOP, partea de server a aplicației web ar putea arăta astfel:

Și cu OOP (după cum puteți vedea, modulele sunt implementate sub formă de clase care conțin doar o metodă, adică clasa nu este necesară aici):

Dar dacă PHP ar fi folosit pentru a nu dezvolta o aplicație de tip server, ci o aplicație client în care partea vizuală generată ar fi stocată în memoria RAM pentru o perioadă lungă de timp și acțiunile utilizatorului ar schimba aceasta, atunci utilizarea OOP poate fi convenabilă. Dar, din nou, OOP este doar o modalitate de organizare a codului, care se bazează pe toate aceleași subrutine (metode) și această metodă de organizare poate nu îi place oricui.

Articole similare

• Cine are nevoie de sfârșitul lumii în fața căruia și de ce este benefic să împingă isteria în masă

• De ce aveți nevoie de un listerman de plăcinte, când există o agenție acvamarină, hr-aqv - secaret cu intim

• Cum să fii dacă ai nevoie de ajutor urgent de la un magician puternic - magie practică

Trimiteți-le prietenilor: