Object-oriented programming (OOP): polimorfism

Programarea este procesul de dezvoltare a soluțiilor pentru sarcini "vii", dinamice, sub forma unor structuri de cod rigide, date, funcții și algoritmi. Procedura de formare a unei sintaxe stricte din semantica incertă. Sarcinile reale reprezintă o problemă cunoscută în sensul

OOP a încercat de două ori să "spargă" acest concept antic de programare, dar "legăturile" stilului clasic de codificare a datelor și algoritmi sunt încă puternice.

Nivel și calificare

Știința informatică a început cu calcule, însă viteza cu care accelerează accelerarea mișcării în sfera procesării informațiilor nu este suficient de mare pentru ca programarea clasică să devină imposibilă și nu mai există.

Și în mod obiectiv, ceea ce dezvoltatorul nu insistă și clientul nu are nevoie de o soluție reală de probleme reale. Ambele părți sunt obișnuite să se limiteze la instrumentele disponibile și la oportunitățile obișnuite.

Formulare polimorfism OOP, incapsularea ideilor și a proprietăților de cod de succesiune (metode) sunt în domeniul programării, dar nu și în zona problemei fiind rezolvată.

Un bun exemplu este biblioteca PHPOffice / PHPWord. Pentru a le folosi, aveți nevoie de calificarea dezvoltatorului, trebuie să creați propriul sistem de obiecte, dar nivelul actual al clientului (cerințele clientului) este o compoziție trivială pe care programatorul o înlocuiește prin dezvoltarea (altfel cerințele nu vor fi îndeplinite). Situația este astfel:

În acest caz, utilizarea bibliotecii este sarcina formatării documentelor, de exemplu, o diplomă sau o teză trebuie standardizată. Clientul și-a prezentat cererile, iar programatorul a mers mult mai departe.

A terminat o analiză completă a documentului, asamblarea acestuia în formatul cerut, executarea lucrărilor cu tabele de orice nivel de cuibărit, îmbinarea și împărțirea celulelor, imprimarea în orice direcție etc.

Polimorfism și OOP

Cea mai bună definiție pentru polimorfism nu este să dai seama cum să te referi la istoria dezvoltării ideii de programare orientată-obiect, atît de populară acum, adesea folosită, dar nerealizat în esență încă.

Fiecare autor are propriul său concept al începutului și esenței PLO. Pentru fiecare cititor atent acest concept este corect și obiectiv. Dar până în prezent, toată lumea acceptă ca axiom necondiționat doar trei poziții:

• încapsulare;
• polimorfism;
• moștenire.

Unii adaugă: abstractizarea și, deseori, aceasta, și, într-adevăr, punctul principal, este folosită ca fundație pentru descrierea esenței OOP.

Astfel, opiniile despre PLO sunt polimorfe: descriu un lucru, sunt proiectate diferit, sau, dimpotrivă, descriu lucruri diferite, însă se bazează pe patru poziții identice.

Deschiderea democratică nu este specifică domeniului tehnologiei informației, ci trebuie acordată atenția cuvenită: combinarea și existența în comun a multor opinii despre același lucru este un polimorfism real în acțiune.

Definiții populare ale polimorfismului

POR este următoarea etapă în dezvoltarea tehnologiilor informaționale. Cu aceasta, foarte puțini oameni argumentează, dar axiomele și pozițiile sale de bază sunt atât de diferite în partea de semantică încât nu merită atenție în afara totalității lor.

1. Polimorfismul în programare este capacitatea de a furniza aceeași interfață pentru diferite forme de bază (tipuri de date).
2. Polimorfismul este capacitatea obiectelor de a avea o implementare diferită.
3. Polimorfismul este abilitatea unei funcții ...
4. Classics (de la creatorul C / C ++): "o interfață - multe implementări".
5. Polimorfismul parametric înseamnă ...
6. Polimorfismul este poziția teoriei tipului ...
7. Abstractizarea este imposibilă fără încapsulare și moștenire, deoarece polimorfismul fără moștenire este imposibil ...

Se poate de acord că toate acestea se referă la același lucru: însă forma exprimării gândului, esenței și conținutului nu sunt similare. Dar este ceva obișnuit.

Esență: dezvoltator-client

Programarea clasică necesită prezența unui programator și a unor sarcini (client, client). Programatorul examinează problema, formalizează-o și face codul care duce la soluție. Clientul neagă toate propunerile sau numai o parte din acesta, evidențiind defecte, iar programatorul își face din nou slujba.

Un astfel de ciclu al procesului de rezolvare a problemei sugerează că două entități complet diferite sunt combinate în mod clar aici:

• Calculatorul nu poate rezolva singur problema;
• Este nevoie de un program astfel încât calculatorul să "înțeleagă" și să "rezolve" problema.

Sarcina este competența clientului, programul este un algoritm de "adaptare" a sarcinii la capacitățile computerului - domeniul de competență al programatorului. Rolul acestuia din urmă este de a "adapta" computerul la cerințele sarcinii, iar acest lucru este de prisos!

Ofertele de programare orientate pe obiecte abstract. Există obiecte - acesta este domeniul de aplicare al clientului - este punerea în aplicare a obiectelor - acesta este domeniul de aplicare al programatorului. Nu există nicio legătură "tehnologică" între client și dezvoltator. Ideea este cardinală, care nu a fost realizată până în prezent, dar ceva funcționează deja în mod constant.

Ferestre, butoane și alte obiecte

Istoria tehnologiilor Air Art, Object Magazine, Turbo Vision, Graph Vision este istorie. Puțini oameni amintesc realizarea OEP, acestea nu sunt folosite și uitate, dar fereastra interfeței Windows este familiară pentru milioane de utilizatori, și obiecte în medii PHP, jаvascript și alte tehnologii de limbi de Internet sunt folosite de sute de mii de dezvoltatori de cod știu despre ele milioane de vizitatori la resurse web.

Probabil, acesta este singurul mod corect în care trebuie să se dezvolte POR: încapsulare, moștenire, polimorfism pentru dezvoltator, dar nu pentru utilizator. Este caracteristic faptul că această poziție a fost cea mai importantă în dezvoltarea designului vizual (interfața) software-ului Windows, al programelor de aplicații precum Turbo Vision și Graph Vision.

Conceptul din spatele produselor Air Art Technology și Object Magazine a fost semnificativ diferit. Aici, obiectul abstract a fost primul strămoș al structurii informaționale, încapsulat la nivel abstract codul de procesare a informațiilor. Obiectele de ferestre, nasturi, elemente vizuale au fost secundare.

În prima versiune (Windows etc) OOP paradigma: încapsulare, moștenire, polimorfism desemnat strămoș nivel abstract și codul de punere în aplicare a format la nivelul fiecărei ramuri în parte moștenirea copilului în funcție de structura și conținutul dorit.

În a doua variantă (Air Art Technology și Object Magazine), nivelul obiectului abstract este important. Ceea ce se va întâmpla cu un anumit descendent nu este esența, principalul lucru este că ramura sa de moștenire îndeplinește cerințele tuturor părinților până la abstractizarea rădăcinilor.

Obiect și sistem de obiecte: algoritm

Un concept ideal orientat spre obiect poate manipula numai obiecte și sisteme obiect.

În limbile moderne de programare, un obiect (clasă) este de obicei înțeles ca o descriere a obiectului și o instanță de obiect și pentru a utiliza descrierea obiectului, limbile permit programatorului să lucreze cu obiecte statice, în timp ce un obiect dinamic - aceasta este o copie Descriere, cu conținutul și structura unică, dar folosind aceleași metode de descriere (proprietăți).

Practica curentă se referă la conceptul de obiect al instrumentului, adică la limbajul de programare, interfața, accesul la baza de date, conexiunea prin rețea, dar nu există nimic care să indice interesul clientului pentru rezolvarea problemei.

Acest lucru este ideal pentru OOP simplu: polimorfismul face posibilă, în special, o varietate de elemente de design, dar să le gestionăm cu același cod. Dar aici nu există nici o îndoială cu privire la obiectele problemei, care nu sunt considerate deloc ca un subiect pentru analiza orientată pe obiecte.

Programatorii au adoptat PLO ca mijloc de îmbunătățire a calității și productivității muncii lor, dar nu au pierdut o picătură de teritoriu pentru client. Conceptele de bază ale POR - incapsulare, moștenire, polimorfism - au rămas în domeniul dezvoltării și nu au fost transplantate în sfera problemei.

Obiect și sistem de obiecte: sarcină și soluție

Un programator de calculator este o sarcină. Legătura de mijloc este inutilă. În mod ideal, ar trebui să existe doar două contururi relativ dependente: (computer - programator) - sarcina. Adică, utilizatorul, clientul sau vizitatorul au un instrument pentru a-și rezolva sarcina. Cum este implementat instrumentul, clientul nu-i pasă.

În mod ideal, este doar un calculator care poate înțelege ceea ce vrea clientul și face ceea ce dorește. Cum va arata: un program local sau un site accesibil printr-un browser, un program special pentru prelucrarea distribuita a informatiilor, un sistem informatic pentru client - nu conteaza.

Este esențial să nu existe nicio legătură excesivă între sarcină și computer, dar prima este de înțeles și poate fi rezolvată de a doua. Pentru a atinge acest obiectiv, iar computerul client trebuie să fie conectat la un sistem de obiecte, iar sensul, structura și conținutul fiecărui obiect definit de către client, precum și metodele și proprietățile obiectelor implementează programator.

În mod ideal, atunci când lucrarea clientului privind crearea sistemului necesar de obiecte și lucrul la implementarea metodelor și proprietăților acestor obiecte sunt separate de timp. Cu cât este mai mult implementarea sistemului de obiecte (programatorul) din conținutul său semantic (clientul), cu atât procesul este mai bun.

Nimic nu împiedică clientul și programator pentru a interacționa în procesul de rezolvare a problemei, dar este important să clar semantica diviziune. Toată lumea trebuie să facă munca lor, programatorul nu este necesară pentru a dezvolta domeniul de aplicare al problemei, iar clientul nu înțelege codul, și cu atât mai mult, părțile nu trebuie să dea reciproc sfaturi pe care nu le privesc.

Programare tradițională și obiect

PLO de bază postulează: încapsulare, moștenire, polimorfism în forma în care acestea au devenit obișnuiți și a susținut, să conducă la o îmbunătățire semnificativă a calității și a fiabilității cod accelera în mod semnificativ de programare de locuri de muncă și au o mulțime de alte calități pozitive.

Dar este încă acolo: programarea clasică nu este inferioară pozițiilor sale și multe idei orientate pe obiecte sunt implementate de codul clasic.

Cu toate acestea, ideea de OEP și recursivitate a condus la o influență corespunzătoare asupra sintaxa operatorilor de sintaxă clasice, logica de a construi cod normale, care nu au nici o legătură cu un stil orientat-obiect de scriere și de gândire.

Listele și rândul său transformat, noțiunea de primul și ultimul element al matrice, au existat cicluri de „fiecare“ și opțiuni de denumire de referință, utilizarea și performanța au devenit mai popular decât oricând înainte.

De fapt, faptul că variabilele au pierdut lor „clare“ față (tipul unei variabile poate fi modificată după cum este necesar, și pentru a descrie variabila nu este necesar), spune că clasice, de fapt, a fost mult timp devenit o și recunoscut principiile de bază ale OOP orientate-obiect: încapsulare , moștenire, polimorfism ca idei de importanță semnificativă.

Ce este la bază: un obiect sau un sistem

Abstractizare, ca poziție conceptuală de bază a OEP, indiferent în cazul în care aria de responsabilitate (implementare) a obiectului - la început un obiect abstract, sau la nivelul unui anumit urmași, - lasă deschisă întrebarea: cum a început totul, cu obiectul sau cu sistemul?

În cazul în care baza pentru a pune un obiect, acesta nu va deveni un sistem, deoarece sistemul va fi amplasat în interiorul acestuia, și el va fi un drum greu început destul de specific. Aici probleme de abstractizare: obiect inițial surprinde cu acuratețe esențial în sarcina la îndemână, adică, nu este transferat într-o altă sarcină.

Dacă sistemul se bazează pe obiecte, se obține un sistem de sisteme. Este greu de imaginat în legătură cu o sarcină specifică și de unde să începeți dezvoltarea este de asemenea greu de înțeles. În ansamblu, polimorfismul OOP cu diferențele sale în entități, forme de implementare, cantitățile de parametri reali din funcții dă idee despre sistemul care se află la început, cum ar fi:

• despre opțiunile de rezolvare a problemei (de exemplu, meniul);
• despre condițiile inițiale (aplicarea problemei în diferite condiții, date);
• privind modurile de operare (testarea, reglarea, munca).

Dar acest lucru și altele asemenea nu-i dau nici un motiv pentru a fundamenta soluția problemei pe un sistem de obiecte. Adesea este suficient să se definească un singur obiect inițial.

Istoria procesului de rezolvare a problemelor

Principiile cele mai importante ale OOP: polimorfismul și abstractizarea - determină prioritatea obiectului inițial ca sistem de obiecte. Într-o dispută care ar trebui să fie mai devreme, un pui sau un ou, victoria se duce la pui.

Nu există nici o îndoială că totul ar trebui să înceapă cu un obiect abstract, și nu cu un sistem de obiecte. Dar dacă luăm în considerare factorul de timp și îl aplicăm la nivelul fiecărui obiect, începând cu primul abstract, atunci ideea contradictorie de a pune soluția obiectului și a sistemului la început este singura soluție rezonabilă.

În cazul în care conceptul clasic de programare în cursul rezolvării problemei se schimbă conținutul de date al bazei de date, modifică fișierele, etc., conceptul OOP de polimorfism, încapsulare, iar factorul timp schimba conținutul, structura și proprietățile obiectelor în problema sistemului care urmează să fie rezolvate.

Programatorul din OOP este mai puțin interesat de conceptul de fișier, de bază de date, de algoritm - acesta este un lucru special, aici programatorul gândește în obiecte, dar obiectele există în timp și schimbă în cursul realizării dorite.

Astfel, la începutul sistemului este obiectul de obiecte și logica acestui sistem - scară de timp: problemă la lansarea, formarea colecției primului obiect, de intrare sau de date, după formarea obiectului, dar nimic nu împiedică primul obiect pentru a începe decizia următoare.

Fiecare nivel obiecte actioneaza ca un sistem de sine stătătoare obiecte, adică, este un singur obiect, ci în contextul începutul valorilor de proces și de timp - un obiect sistem pe cronologie. Pentru punerea în aplicare completă a polimorfism OOP, moștenire, și factorul timp se combină pentru a oferi dinamica primul, adică, nu numai că se poate schimba în timp, dar da naștere unor obiecte care nu sunt furnizate de către dezvoltator generate în cursul executării sarcinilor procesului, clientul proiectat.

Real polimorfismul PPE, de exemplu

Complexitatea sarcinilor, pe care forțele PLO nu le compară cu cele disponibile pentru versiunea clasică a programelor de scriere. Desigur, rezolvarea oricărei probleme este întotdeauna disponibilă în mod obișnuit, dar întrebarea cât de mult va costa timpul și efortul de multe ori face ca rezultatul să fie inutil.

Nu cu mult timp în urmă, biblioteca PHPOffice / PHPWord a fost dezvoltată, dar pentru a-și folosi capabilitățile, aproape întotdeauna trebuie să creați propriul sistem de obiecte. De exemplu, un fișier * .docx simplu:

este o arhivă zip mai multe fișiere și foldere în format (OpenXML, OOXML), XML Office Open. Fiecare fișier este scris în etichete XML, cu atunci când adăugarea, modificarea și ștergerea litere, cuvinte, tabele, liste, și așa mai departe. Conținutul Elemente de fișiere începe să reprezinte o secvență de tag-uri care nu sunt întotdeauna conțin elemente complet, un element este adesea înregistrat mai multe etichete.

Dacă reprezentați acest fișier ca o secvență de etichete, veți obține o imagine interesantă:

Este ușor de văzut că primul și singurul paragraf al documentului este reprezentat de un set de etichete. În ceea ce privește masa, și încorporate în ea tabele, cantitatea de descrieri ale tuturor elementelor care nu pot fi percepția, dar disponibile aplicațiile orientate pe obiect.

De fapt, în figura verde este ieșirea de testare a etichetelor, galben este parametrii și tipul etichetei, conținutul bej este. Obiectele create sunt orientate către prelucrarea mașinilor. Pentru o persoană, devin disponibile numai operațiunile de deschidere a unui fișier de document, formatarea și înregistrarea acestuia.

Soluția este simplă și practică, dar implementarea este mai degrabă centrică pe computer decât pe om, datorită numărului mare de funcții efectuate și relațiilor complexe dintre obiecte.

Starea regiunii OOP

Dezvoltarea sistemelor de management al site-ului, a tehnologiilor de configurare și gestionare a serverului, experiență în dezvoltarea de site-uri dinamice, a făcut programarea orientată pe obiecte accesibilă tuturor. Problema este cum să vă schimbați gândirea și să vă obișnuiți să gândiți la nivelul obiectelor, mai degrabă decât în ​​contextul unui cod executabil în mod constant.

În mod tipic, trecerea de la programarea clasică la orientarea obiectului durează două până la trei luni, însă costurile se plătesc cu dobândă. Potențialul limbajelor moderne de programare, în primul rând PHP și jаvascript, va satisface cel mai sofisticat dezvoltator.

POO modernă - polimorfismul, moștenirea și capacitatea de a forma proprietățile obiectelor - sunt convenabile și practice, sintaxa limbilor și a instrumentelor auxiliare oferă confort în muncă și eficiența codului.

Perspectivele ideii obiective

Cât timp va avea loc programarea clasică și cum se va dezvolta POR? E greu de spus. Se pare că dezvoltatorii de instrumente nu intenționează să ia în considerare contextul consumatorului (utilizator, client).

Instrumentele OOP - polimorfism, moștenire, încapsulare și abstractizare - sunt orientate spre dezvoltator.

Sistemele moderne de informare și resurse bazate pe web tind să reflecte realitatea, pentru a asigura buna funcționare a obiectelor reale și de a crea un mediu pentru ca acestea să funcționeze, atât de simplu încât acesta va fi disponibil pentru consumator, departe de programare, complet cufundat în sfera competenței sale.