{"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\/sq\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 parimet e programimit t\u00eb orientuar nga objektet q\u00eb \u00e7do zhvillues duhet t\u00eb dij\u00eb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nShum\u00eb shpesh takoj zhvillues q\u00eb nuk kan\u00eb d\u00ebgjuar p\u00ebr parimet SOLID (ne i kemi p\u00ebrshkruar n\u00eb detaje k\u00ebtu<\/a><\/noindex>. \u2014 P\u00ebr.) ose p\u00ebr Programimin e Orientuar n\u00eb Objekt (OOP), ose kan\u00eb d\u00ebgjuar, por nuk i p\u00ebrdorin ato n\u00eb praktik\u00eb. N\u00eb k\u00ebt\u00eb artikel p\u00ebrshkruhen avantazhet e parimeve OOP q\u00eb ndihmojn\u00eb zhvilluesin n\u00eb pun\u00ebn e tij t\u00eb p\u00ebrditshme. Disa nga ato jan\u00eb t\u00eb njohura mir\u00eb, t\u00eb tjerat jo shum\u00eb, k\u00ebshtu q\u00eb artikulli do t\u00eb jet\u00eb i dobish\u00ebm si p\u00ebr fillestar\u00ebt, ashtu edhe p\u00ebr programuesit me p\u00ebrvoj\u00eb.
\n<\/a><\/noindex><\/p>\n

Kujtojm\u00eb:<\/b> p\u00ebr t\u00eb gjith\u00eb lexuesit e \"Habra\" \u2014 zbritje prej 10,000 rubla p\u00ebr regjistrimin n\u00eb \u00e7do kurs Skillbox me kodin promocional \"Habra\".<\/i><\/p>\n

Skillbox rekomandon:<\/b> Kurs online edukativ \"Zhvillues Java\"<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Mos u p\u00ebrs\u00ebrit vet\u00eb)<\/h3>\n

\nNj\u00eb princip mjaft i thjesht\u00eb, thelbi i t\u00eb cilit \u00ebsht\u00eb i qart\u00eb nga emri: \"Mos u p\u00ebrs\u00ebrit\". P\u00ebr programuesin kjo do t\u00eb thot\u00eb nevoja p\u00ebr t\u00eb u shmangur nga kodi i dyfisht\u00eb, si dhe mund\u00ebsia p\u00ebr t\u00eb p\u00ebrdorur abstraksionin n\u00eb pun\u00ebn e tij.<\/p>\n

N\u00ebse n\u00eb kod ka dy segmente t\u00eb p\u00ebrs\u00ebritura, ata duhet t\u00eb bashkohen n\u00eb nj\u00eb metod\u00eb. N\u00ebse nj\u00eb vler\u00eb e caktuar p\u00ebrdoret m\u00eb shum\u00eb se nj\u00eb her\u00eb, ajo duhet t\u00eb kthehet n\u00eb nj\u00eb konstant\u00eb publike.<\/p>\n

Kjo \u00ebsht\u00eb e nevojshme p\u00ebr t\u00eb thjeshtuar kodin dhe p\u00ebr ta b\u00ebr\u00eb mb\u00ebshtetje m\u00eb t\u00eb leht\u00eb, q\u00eb \u00ebsht\u00eb objekti kryesor i OOP. Nuk duhet abuzuar me bashkimin gjithashtu, pasi i nj\u00ebjti kod nuk do t\u00eb kaloj\u00eb verifikimin si me OrderId ashtu edhe me SSN.<\/p>\n

Encapsulimi i ndryshimeve<\/h3>\n

\nProduktet softuerike t\u00eb shumic\u00ebs s\u00eb kompanive vazhdimisht zhvillohen. Kjo do t\u00eb thot\u00eb se nevojiten ndryshime n\u00eb kod, ai duhet mbajtur. Mund ta leht\u00ebsoni jet\u00ebn tuaj me an\u00eb t\u00eb encapsulimit. Kjo do t\u00eb lejoj\u00eb q\u00eb t\u00eb testoni dhe mbani m\u00eb efektivisht baz\u00ebn ekzistuese t\u00eb kodit. K\u00ebtu \u00ebsht\u00eb nj\u00eb nga shembujt<\/a><\/noindex>.<\/p>\n

N\u00ebse shkruani n\u00eb Java, at\u00ebher\u00eb ndryshe caktoni si private p\u00ebr metodat dhe variablat<\/a><\/noindex>.<\/p>\n

Principi i hapjes\/zierjes<\/h3>\n

\nKy princip mund t\u00eb mbetet leht\u00eb n\u00eb mendje duke lexuar deklarat\u00ebn e m\u00ebposhtme: \"Entitetet softuerike (klasa, module, funksione etj.) duhet t\u00eb jen\u00eb t\u00eb hapura p\u00ebr zgjerim, por t\u00eb mbyllura p\u00ebr ndryshim\". N\u00eb praktik\u00eb, kjo do t\u00eb thot\u00eb se ata mund t\u00eb lejojn\u00eb t\u00eb ndryshojn\u00eb sjelljen e tyre pa ndryshuar kodin burim.<\/p>\n

Principi \u00ebsht\u00eb i r\u00ebnd\u00ebsish\u00ebm, kur ndryshimet n\u00eb kodin burim k\u00ebrkojn\u00eb nj\u00eb rishikim t\u00eb tij, teste modulare dhe procedura t\u00eb tjera. Kodi q\u00eb p\u00ebrgatitet sipas prinsipin e hapjes\/zierjes nuk ndryshon kur zgjeron, prandaj ka shum\u00eb pak probleme me t\u00eb.<\/p>\n

Ja, ky \u00ebsht\u00eb nj\u00eb shembull kodi q\u00eb shkel k\u00ebt\u00eb parim.<\/p>\n

\"10
\n
\nN\u00ebse do t\u00eb ket\u00eb nevoj\u00eb p\u00ebr ndonj\u00eb ndryshim, do t\u00eb duhen shum\u00eb koh\u00eb, pasi do t\u00eb duhet t\u00eb ndryshohen t\u00eb gjitha pjes\u00ebt e kodit q\u00eb kan\u00eb lidhje me fragmentin e nevojsh\u00ebm.<\/p>\n

Nga ana tjet\u00ebr, hapja-mbyllja \u00ebsht\u00eb nj\u00eb nga parimet e SOLID.<\/p>\n

Parimi i p\u00ebrgjegj\u00ebsis\u00eb s\u00eb vetme (SRP)<\/h3>\n

\nNj\u00eb parim tjet\u00ebr nga grupi SOLID. Ai thot\u00eb se \"ka vet\u00ebm nj\u00eb arsye q\u00eb e \u00e7on n\u00eb ndryshimin e nj\u00eb klase\". Klasa zgjidh vet\u00ebm nj\u00eb detyr\u00eb. Ajo mund t\u00eb ket\u00eb disa metoda, por secila prej tyre p\u00ebrdoret vet\u00ebm p\u00ebr t\u00eb zgjidhur detyr\u00ebn e p\u00ebrgjithshme. T\u00eb gjitha metodat dhe pron\u00ebsit\u00eb duhet t\u00eb sh\u00ebrbejn\u00eb vet\u00ebm p\u00ebr k\u00ebt\u00eb. <\/p>\n

\"10
\n
\nVlera e k\u00ebtij parimi \u00ebsht\u00eb se ai leht\u00ebson lidhjen midis komponent\u00ebve t\u00eb ve\u00e7ant\u00eb t\u00eb softuerit dhe kodit. N\u00ebse shtoni m\u00eb shum\u00eb se nj\u00eb funksionalitet n\u00eb nj\u00eb klas\u00eb, kjo krijon nj\u00eb lidhje midis dy funksioneve. K\u00ebshtu, n\u00ebse ndryshoni nj\u00eb prej tyre, ka mund\u00ebsi t\u00eb madhe t\u00eb prishni tjetr\u00ebn, e cila \u00ebsht\u00eb e lidhur me t\u00eb par\u00ebn. Kjo do t\u00eb thot\u00eb rritje t\u00eb cikleve t\u00eb testimit p\u00ebr t\u00eb zbuluar t\u00eb gjitha problemet paraprakisht.<\/p>\n

Parimi i inverzimit t\u00eb var\u00ebsive (DIP)<\/h3>\n

\n\"10
\n
\nM\u00eb lart \u00ebsht\u00eb nj\u00eb shembull kodi, ku AppManager varet nga EventLogWriter, i cili, nga ana tjet\u00ebr, \u00ebsht\u00eb ngusht\u00ebsisht i lidhur me AppManager. N\u00ebse nevojitet nj\u00eb m\u00ebnyr\u00eb tjet\u00ebr p\u00ebr t\u00eb treguar njoftimin, qofshin k\u00ebto push, SMS ose email, duhet t\u00eb ndryshohet klasa AppManager.<\/p>\n

Problemi mund t\u00eb zgjidhet duke p\u00ebrfshir\u00eb DIP. Pra, n\u00eb vend t\u00eb AppManager, ne k\u00ebrkojm\u00eb EventLogWriter, i cili do t\u00eb futet p\u00ebrmes nj\u00eb framework.<\/p>\n

DIP ofron mund\u00ebsin\u00eb e z\u00ebvend\u00ebsimit t\u00eb moduleve t\u00eb ve\u00e7anta me t\u00eb tjera, duke ndryshuar modulun e var\u00ebsis\u00eb. Kjo ofron mund\u00ebsin\u00eb p\u00ebr t\u00eb ndryshuar nj\u00eb modul, pa ndikuar n\u00eb pjes\u00ebt e tjera.<\/p>\n

Kompozita n\u00eb vend t\u00eb trash\u00ebgimis\u00eb<\/h3>\n

\n\"10Ka dy m\u00ebnyra kryesore p\u00ebr t\u00eb rip\u00ebrdorur kodin - trash\u00ebgim dhe kompozit\u00eb, secila prej t\u00eb cilave ka avantazhe dhe disavantazhe t\u00eb saj. Zakonisht preferohet e dyta, pasi \u00ebsht\u00eb m\u00eb fleksib\u00ebl.<\/p>\n

Kompozita ofron mund\u00ebsin\u00eb p\u00ebr t\u00eb ndryshuar sjelljen e klas\u00ebs gjat\u00eb ekzekutimit p\u00ebrmes caktimit t\u00eb pron\u00ebsive t\u00eb saj. Kur implementohen nd\u00ebrfaqet, p\u00ebrdoret polimorfizmi, i cili ofron nj\u00eb implementim m\u00eb fleksib\u00ebl.<\/p>\n

Madje \"Effective Java\" e Joshua Bloch rekomandon q\u00eb t\u00eb preferohet kompozita p\u00ebrpara trash\u00ebgimis\u00eb.<\/p>\n

Parimi i z\u00ebvend\u00ebsimit t\u00eb Barbara Liskov (LSP)<\/h3>\n

\nNj\u00eb tjet\u00ebr parim nga pajisjet e SOLID. Ai thot\u00eb se n\u00ebnklasat duhet t\u00eb jen\u00eb t\u00eb z\u00ebvend\u00ebsueshme p\u00ebr superklas\u00ebn. K\u00ebshtu, metodat dhe funksionet q\u00eb punojn\u00eb me superklas\u00ebn, duhet t\u00eb ken\u00eb mund\u00ebsi t\u00eb punojn\u00eb pa probleme edhe me n\u00ebnklasat e saj.<\/p>\n

LSP \u00ebsht\u00eb i lidhur si me parimin e p\u00ebrgjegj\u00ebsis\u00eb s\u00eb vetme ashtu edhe me parimin e ndarjes s\u00eb p\u00ebrgjegj\u00ebsis\u00eb. N\u00ebse nj\u00eb klas\u00eb ofron m\u00eb shum\u00eb funksionalitet se sa n\u00ebnklasa, at\u00ebher\u00eb kjo e fundit nuk do t\u00eb mb\u00ebshtes\u00eb disa funksione, duke shkelur k\u00ebt\u00eb parim.<\/p>\n

Ja nj\u00eb pjes\u00eb kodi q\u00eb bie n\u00eb kund\u00ebrshtim me LSP.<\/p>\n

\"10
\n
\nMetoda area(Rectangle r) llogarit sip\u00ebrfaqen e Rectangle. Programi do t\u00eb bjer\u00eb pas ekzekutimit t\u00eb Square, pasi Square k\u00ebtu nuk \u00ebsht\u00eb nj\u00eb Rectangle. Sipas parimit LSP, funksionet q\u00eb p\u00ebrdorin referencia ndaj klasave themelore duhet t\u00eb ken\u00eb mund\u00ebsi t\u00eb p\u00ebrdorin edhe objekte nga klasat e p\u00ebrftuara pa instruksione t\u00eb tjera.<\/p>\n

Ky parim, i cili do t\u00eb thot\u00eb specifike p\u00ebr definimin e n\u00ebnklas\u00ebs, u propozuar nga Barbara Liskov n\u00eb vitin 1987 n\u00eb nj\u00eb konferenc\u00eb n\u00eb prezantimin e saj kryesor me titull \"Abstraksioni e t\u00eb dh\u00ebnave dhe hierarkia\" \u2014 prej andej erdhi edhe emri i tij.<\/p>\n

Parimi i ndarjes s\u00eb nd\u00ebrfaqeve (ISP)<\/h3>\n

\nNj\u00eb tjet\u00ebr parim i SOLID. Sipas tij, nj\u00eb nd\u00ebrfaqe q\u00eb nuk p\u00ebrdoret nuk duhet t\u00eb implementohet. Ndjekja e k\u00ebtij parimi ndihmon sistemin t\u00eb mbetet fleksib\u00ebl dhe i p\u00ebrshtatsh\u00ebm p\u00ebr ristrukturim kur b\u00ebhen ndryshime n\u00eb logjik\u00ebn e pun\u00ebs.<\/p>\n

Kjo situat\u00eb ndodh shpesh kur nd\u00ebrfaqja ka disa funksionalitete, dhe klienti ka nevoj\u00eb vet\u00ebm p\u00ebr nj\u00ebrin prej tyre.<\/p>\n

Duke qen\u00eb se shkruarja e nj\u00eb nd\u00ebrfaqeje \u00ebsht\u00eb nj\u00eb detyr\u00eb e v\u00ebshtir\u00eb, pas p\u00ebrfundimit t\u00eb pun\u00ebs, ndryshimi i saj pa shkaktuar probleme do t\u00eb jet\u00eb nj\u00eb sfid\u00eb.<\/p>\n

Avantazhi i parimit ISP n\u00eb Java \u00ebsht\u00eb se s\u00eb pari duhet t\u00eb implementohen t\u00eb gjitha metodat, dhe pastaj ato mund t\u00eb p\u00ebrdoren nga klasat. Prandaj, parimi ofron mund\u00ebsin\u00eb p\u00ebr t\u00eb reduktuar numrin e metodave.<\/p>\n

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

Programimi p\u00ebr nd\u00ebrfaqen, jo p\u00ebr implementimin<\/h3>\n

\nK\u00ebtu gjith\u00e7ka \u00ebsht\u00eb e qart\u00eb nga emri. Zbatimi i k\u00ebtij parimi \u00e7on n\u00eb krijimin e kodit fleksib\u00ebl, i cili do t\u00eb mund t\u00eb punoj\u00eb me \u00e7do implementim t\u00eb ri t\u00eb nd\u00ebrfaqes.<\/p>\n

Duhet t\u00eb p\u00ebrdoret tipi i nd\u00ebrfaqes p\u00ebr variablat, tipet e kthimit ose p\u00ebr tipin e argumentit t\u00eb metod\u00ebs. Shembulli \u2014 p\u00ebrdorimi i SuperClass, jo SubClass.<\/p>\n

Pra:<\/p>\n

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

Dhe jo:<\/p>\n

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

K\u00ebtu \u00ebsht\u00eb nj\u00eb implementim praktik i asaj q\u00eb u tha m\u00eb sip\u00ebr.<\/p>\n

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

Principi i delegimit<\/h3>\n

\nNj\u00eb shembull i zakonsh\u00ebm \u00ebsht\u00eb metodat equals() dhe hashCode() n\u00eb Java. Kur nevojitet t\u00eb krahasohen dy objekte, ky veprim i delegohet klas\u00ebs p\u00ebrkat\u00ebse n\u00eb vend t\u00eb klientit.<\/p>\n

Avantazhi i k\u00ebtij principi \u00ebsht\u00eb mungesa e p\u00ebrs\u00ebritjes s\u00eb kodit dhe ndryshimi relativisht i thjesht\u00eb i sjelljes. Gjithashtu, ai \u00ebsht\u00eb i aplikuesh\u00ebm p\u00ebr delegimin e ngjarjeve.<\/p>\n

\"10
\n
\nT\u00eb gjith\u00eb k\u00ebta principe lejojn\u00eb t\u00eb shkruhet kod m\u00eb fleksib\u00ebl, m\u00eb elegant dhe m\u00eb t\u00eb besuesh\u00ebm me lidhshm\u00ebri t\u00eb lart\u00eb dhe ngjitje t\u00eb ul\u00ebt. Sigurisht, teoria \u00ebsht\u00eb e mir\u00eb, por q\u00eb nj\u00eb zhvillues t\u00eb filloj\u00eb t\u00eb p\u00ebrdor\u00eb realisht njohurit\u00eb e fituara, nevojitet praktika. Hapi i ardhsh\u00ebm pas p\u00ebrvet\u00ebsimit t\u00eb parimeve t\u00eb OOP mund t\u00eb jet\u00eb studimi i modeleve t\u00eb dizajnit p\u00ebr t\u00eb zgjidhur probleme t\u00eb zakonshme n\u00eb zhvillimin e softuer\u00ebve.<\/p>\n

Skillbox rekomandon:<\/b><\/p>\n