{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principii de programare orientat\u0103 pe obiect pe care fiecare dezvoltator ar trebui s\u0103 le cunoasc\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\n\u00cent\u00e2lnesc destul de des dezvoltatori care nu au auzit de principiile SOLID (noi am vorbit \u00een detaliu despre acestea aici<\/a><\/noindex>. \u2014 Nota.) sau de programarea orientat\u0103 pe obiect (OOP), sau au auzit, dar nu le folosesc \u00een practic\u0103. \u00cen acest articol sunt descrise avantajele principiilor OOP, care ajut\u0103 dezvoltatorul \u00een munca sa zilnic\u0103. Unele dintre ele sunt bine cunoscute, altele \u2014 mai pu\u021bin, astfel c\u0103 articolul va fi util at\u00e2t pentru \u00eencep\u0103tori, c\u00e2t \u0219i pentru programatori cu experien\u021b\u0103.
\n<\/a><\/noindex><\/p>\n

V\u0103 reamintim:<\/b> pentru to\u021bi cititorii \u00ab\u00bbHabr\u00bb \u2014 o reducere de 10 000 de ruble la \u00eenscrierea la orice curs Skillbox cu codul promo\u021bional \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox recomand\u0103:<\/b> Curs online educa\u021bional \u00abDezvoltator Java\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nUn principiu destul de simplu, a c\u0103rui esen\u021b\u0103 este clar\u0103 din nume: \u00abNu te repeta\u00bb. Pentru programator, aceasta \u00eenseamn\u0103 necesitatea de a evita codul duplicat, precum \u0219i posibilitatea de a folosi abstrac\u021bia \u00een munc\u0103.<\/p>\n

Dac\u0103 \u00een cod exist\u0103 dou\u0103 p\u0103r\u021bi repetate, ar trebui s\u0103 le unifici \u00eentr-o metod\u0103. Dac\u0103 o valoare fix\u0103 este utilizat\u0103 de mai multe ori, ar trebui s\u0103 o transformi \u00eentr-o constant\u0103 public\u0103.<\/p>\n

Acest lucru este necesar pentru a simplifica codul \u0219i a face \u00eentre\u021binerea acestuia mai u\u0219oar\u0103, ceea ce este principalul obiectiv al OOP. Nu trebuie s\u0103 abuzi de unificare, deoarece acela\u0219i cod nu va trece testul at\u00e2t cu OrderId, c\u00e2t \u0219i cu SSN.<\/p>\n

\u00cencapsularea schimb\u0103rilor<\/h3>\n

\nProdusele software ale celor mai multe companii sunt \u00een continu\u0103 dezvoltare. Asta \u00eenseamn\u0103 c\u0103 trebuie f\u0103cute modific\u0103ri \u00een cod, acesta trebuie \u00eentre\u021binut. \u00ce\u021bi po\u021bi simplifica via\u021ba prin intermediul \u00eencapsul\u0103rii. Aceasta va permite testarea \u0219i \u00eentre\u021binerea mai eficient\u0103 a bazei de cod existente. Iat\u0103 unul dintre exemple<\/a><\/noindex>.<\/p>\n

Dac\u0103 scrii \u00een Java, atunci prin default, atribuie metod\u0103 \u0219i variabile private<\/a><\/noindex>.<\/p>\n

Principiul deschiderii\/\u00eenchiderii<\/h3>\n

\nAcest principiu poate fi u\u0219or re\u021binut citind urm\u0103toarea afirma\u021bie: \u00abEntit\u0103\u021bile software (clase, module, func\u021bii etc.) trebuie s\u0103 fie deschise pentru extensie, dar \u00eenchise pentru modificare\u00bb. \u00cen practic\u0103, aceasta \u00eenseamn\u0103 c\u0103 ele pot permite schimbarea comportamentului lor f\u0103r\u0103 a modifica codul surs\u0103.<\/p>\n

Principiul este important atunci c\u00e2nd modific\u0103rile \u00een codul surs\u0103 necesit\u0103 revizuirea acestuia, testarea modular\u0103 \u0219i alte proceduri. Codul care respect\u0103 principiul deschiderii\/\u00eenchiderii nu este modificat atunci c\u00e2nd este extins, a\u0219adar \u00eent\u00e2mpin\u0103 mult mai pu\u021bine probleme.<\/p>\n

Iat\u0103 un exemplu de cod care \u00eencalc\u0103 acest principiu.<\/p>\n

\"10
\n
\nDac\u0103 va fi necesar s\u0103 modific\u0103m ceva, va dura mult timp, deoarece va trebui s\u0103 schimb\u0103m toate p\u0103r\u021bile de cod care sunt legate de fragmentul dorit.<\/p>\n

Apropo, principiul deschiderii \u0219i \u00eenchiderii este unul dintre principiile SOLID.<\/p>\n

Principiul responsabilit\u0103\u021bii unice (SRP)<\/h3>\n

\nUn alt principiu din setul SOLID. Acesta afirm\u0103 c\u0103 \u201eexist\u0103 doar un motiv pentru a schimba o clas\u0103\u201d. O clas\u0103 rezolv\u0103 doar o singur\u0103 problem\u0103. Poate avea mai multe metode, dar fiecare dintre ele este utilizat\u0103 doar pentru a rezolva sarcina general\u0103. Toate metodele \u0219i propriet\u0103\u021bile trebuie s\u0103 serveasc\u0103 doar acestui scop. <\/p>\n

\"10
\n
\nValoarea acestui principiu const\u0103 \u00een faptul c\u0103 sl\u0103be\u0219te leg\u0103tura dintre un anumit component de software \u0219i cod. Dac\u0103 se adaug\u0103 mai mult\u0103 func\u021bionalitate \u00eentr-o clas\u0103, aceasta introduce o leg\u0103tur\u0103 \u00eentre dou\u0103 func\u021bii. Astfel, dac\u0103 se schimb\u0103 una dintre ele, exist\u0103 o mare probabilitate s\u0103 afecteze a doua, care este legat\u0103 de prima. \u0218i aceasta \u00eenseamn\u0103 cre\u0219terea ciclurilor de testare pentru a identifica toate problemele din timp.<\/p>\n

Principiul invers\u0103rii dependen\u021belor (DIP)<\/h3>\n

\n\"10
\n
\nMai sus este un exemplu de cod, unde AppManager depinde de EventLogWriter, care, la r\u00e2ndul s\u0103u, este str\u00e2ns legat de AppManager. Dac\u0103 este nevoie de o alt\u0103 metod\u0103 de a ar\u0103ta notificarea, fie c\u0103 este vorba de push, SMS sau email, va trebui s\u0103 modific\u0103m clasa AppManager.<\/p>\n

Problema poate fi rezolvat\u0103 cu ajutorul DIP. Astfel, \u00een loc de AppManager, cerem EventLogWriter, care va fi introdus cu ajutorul framework-ului.<\/p>\n

DIP permite \u00eenlocuirea f\u0103r\u0103 probleme a modulelor individuale cu altele, prin modificarea modulului de dependen\u021b\u0103. Aceasta ofer\u0103 posibilitatea de a modifica un modul f\u0103r\u0103 a afecta restul.<\/p>\n

Compozi\u021bie \u00een loc de mo\u0219tenire<\/h3>\n

\n\"10Exist\u0103 dou\u0103 moduri principale de a reutiliza codul \u2014 mo\u0219tenirea \u0219i compozi\u021bia, fiecare av\u00e2nd propriile avantaje \u0219i dezavantaje. De obicei, se prefer\u0103 a doua, deoarece este mai flexibil\u0103.<\/p>\n

Compozi\u021bia ofer\u0103 posibilitatea de a schimba comportamentul unei clase \u00een timpul execu\u021biei prin setarea propriet\u0103\u021bilor sale. La implementarea interfe\u021belor se folose\u0219te polimorfismul, care ofer\u0103 o implementare mai flexibil\u0103.<\/p>\n

Chiar \u0219i \u201eEffective Java\u201d de Joshua Bloch recomand\u0103 s\u0103 se prefere compozi\u021bia \u00een locul mo\u0219tenirii.<\/p>\n

Principiul substi\u021biei Barbara Liskov (LSP)<\/h3>\n

\n\u00cenc\u0103 un principiu din instrumentarul SOLID. Acesta afirm\u0103 c\u0103 subtipurile trebuie s\u0103 fie substituibile pentru supertip. Asta \u00eenseamn\u0103 c\u0103 metodele \u0219i func\u021biile care lucreaz\u0103 cu superclasa trebuie s\u0103 poat\u0103 func\u021biona f\u0103r\u0103 probleme \u0219i cu subclasele acesteia.<\/p>\n

LSP este legat at\u00e2t de principiul responsabilit\u0103\u021bii unice, c\u00e2t \u0219i de principiul separ\u0103rii responsabilit\u0103\u021bilor. Dac\u0103 o clas\u0103 ofer\u0103 mai multe func\u021bionalit\u0103\u021bi dec\u00e2t subclasa, atunci aceasta din urm\u0103 nu va sus\u021bine anumite func\u021bii, \u00eenc\u0103lc\u00e2nd acest principiu.<\/p>\n

Iat\u0103 un fragment de cod care contrazice LSP.<\/p>\n

\"10
\n
\nMetoda area(Rectangle r) calculeaz\u0103 aria Rectangle. Programul va c\u0103dea dup\u0103 executarea lui Square, deoarece Square nu este un Rectangle aici. Conform principiului LSP, func\u021biile care folosesc referin\u021be la clasele de baz\u0103 trebuie s\u0103 fie capabile s\u0103 utilizeze \u0219i obiectele claselor derivate f\u0103r\u0103 instruc\u021biuni suplimentare.<\/p>\n

Acest principiu, care este o defini\u021bie specific\u0103 a subtipului, a fost propus de Barbara Liskov \u00een 1987 la o conferin\u021b\u0103 \u00een cadrul unei sesiuni plenare intitulate \u201eAbstrac\u021bia datelor \u0219i ierarhia\u201d \u2014 de aici \u0219i denumirea sa.<\/p>\n

Principiul separ\u0103rii interfe\u021bei (ISP)<\/h3>\n

\n\u00cenc\u0103 un principiu SOLID. Conform acestuia, o interfa\u021b\u0103 care nu este folosit\u0103 nu trebuie implementat\u0103. Urmarea acestui principiu ajut\u0103 sistemul s\u0103 r\u0103m\u00e2n\u0103 flexibil \u0219i u\u0219or de refactorizat atunci c\u00e2nd se fac modific\u0103ri \u00een logica de func\u021bionare.<\/p>\n

Cea mai frecvent\u0103 situa\u021bie apare atunci c\u00e2nd interfa\u021ba con\u021bine mai multe func\u021bionalit\u0103\u021bi, iar clientul are nevoie doar de una dintre ele.<\/p>\n

Deoarece scrierea unei interfe\u021be este o sarcin\u0103 complicat\u0103, dup\u0103 finalizarea lucr\u0103rii, modificarea acesteia f\u0103r\u0103 a \u00eenc\u0103lca nimic va fi o problem\u0103.<\/p>\n

Avantajul principiului ISP \u00een Java este c\u0103 mai \u00eent\u00e2i trebuie implementate toate metodele, iar abia apoi ele pot fi utilizate de c\u0103tre clase. Prin urmare, acest principiu permite reducerea num\u0103rului de metode.<\/p>\n

\"10
\n <\/p>\n

Programare pentru interfa\u021b\u0103, nu pentru implementare<\/h3>\n

\nAici totul este clar din denumire. Aplicarea acestui principiu duce la crearea unui cod flexibil, care poate func\u021biona cu orice nou\u0103 implementare a interfe\u021bei.<\/p>\n

Trebuie s\u0103 folose\u0219ti tipul interfe\u021bei pentru variabile, tipuri returnate sau tipul argumentului metodei. Exemplu \u2014 utilizarea SuperClass, nu SubClass.<\/p>\n

Adic\u0103:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

\u0218i nu:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Iat\u0103 o implementare practic\u0103 a celor spuse mai sus.<\/p>\n

\"10
\n <\/p>\n

Principiul deleg\u0103rii<\/h3>\n

\nUn exemplu comun este metodele equals() \u0219i hashCode() \u00een Java. C\u00e2nd este necesar\u0103 compararea a dou\u0103 obiecte, aceast\u0103 ac\u021biune este delegat\u0103 clasei corespunz\u0103toare \u00een loc de client.<\/p>\n

Avantajul principiului este absen\u021ba duplic\u0103rii codului \u0219i schimbarea relativ simpl\u0103 a comportamentului. De asemenea, este aplicabil pentru delegarea evenimentelor.<\/p>\n

\"10
\n
\nToate aceste principii permit scrierea de cod mai flexibil, mai frumos \u0219i mai fiabil, cu o conectivitate ridicat\u0103 \u0219i un cuplaj sc\u0103zut. Desigur, teoria este important\u0103, dar pentru ca un dezvoltator s\u0103 foloseasc\u0103 cu adev\u0103rat cuno\u0219tin\u021bele dob\u00e2ndite, este necesar\u0103 practica. Urm\u0103torul pas dup\u0103 st\u0103p\u00e2nirea principiilor OOP ar putea fi studiul modelor de proiectare pentru rezolvarea problemelor comune de dezvoltare a software-ului.<\/p>\n

Skillbox recomand\u0103:<\/b><\/p>\n