{"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\/et\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 objektorienteeritud programmeerimise p\u00f5him\u00f5tet, millest iga arendaja peaks teadma","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nMa sageli kohtan arendajaid, kes ei ole kuulnud SOLIDi p\u00f5him\u00f5tetest (me r\u00e4\u00e4kisime neist siin p\u00f5hjalikult<\/a><\/noindex>. \u2014 Toim.) v\u00f5i objektorienteeritud programmeerimisest (OOP), v\u00f5i on kuulnud, kuid ei kasuta neid praktikas. Selles artiklis k\u00e4sitletakse OOP p\u00f5him\u00f5tete eeliseid, mis aitavad arendajal tema igap\u00e4evases t\u00f6\u00f6s. M\u00f5ned neist on h\u00e4sti tuntud, teised mitte nii v\u00e4ga, seega on artikkel kasulik nii algajatele kui ka kogenenud programmeerijatele.
\n<\/a><\/noindex><\/p>\n

Tuletame meelde:<\/b> k\u00f5ikidele \"Habbra\" lugejatele \u2014 10 000 rubla allahindlus, kui registreerite end Skillboxi kursusele promokoodiga \"Habr\".<\/i><\/p>\n

Skillbox soovitab:<\/b> Haridusalane veebikursus Java arendaja<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (\u00c4ra Korda End)<\/h3>\n

\nSuhteliselt lihtne p\u00f5him\u00f5te, mille olemus on selge juba nimest: \"\u00c4ra korda end\". Programmeerija jaoks t\u00e4hendab see vajadust v\u00e4ltida dubleeritud koodi ja v\u00f5imalust kasutada t\u00f6\u00f6s abstraktsioone.<\/p>\n

Kui koodis on kaks korduvat osa, tuleks need liita \u00fcheks meetodiks. Kui kindel v\u00e4\u00e4rtus on kasutusel rohkem kui \u00fcks kord, tasub see muundada avalikuks konstantsiks.<\/p>\n

See on vajalik, et lihtsustada koodi ja teha selle hooldamine kergemaks, mis on OOP p\u00f5hiline eesm\u00e4rk. Liialdamine liitmisega ei ole ka soovitatav, kuna sama kood ei saa samaaegselt toimida nii OrderId kui ka SSN-iga.<\/p>\n

Muutuste kapseldamine<\/h3>\n

\nEnamiku ettev\u00f5tete tarkvaraproduktid arenevad pidevalt. See t\u00e4hendab, et koodi tuleb muuta, seda peab hooldama. Oma elu lihtsustamiseks saab kasutada kapseldamist. See v\u00f5imaldab t\u00f5husamalt testida ja hooldada olemasolevat koodibaasi. Siin on \u00fcks n\u00e4ide<\/a><\/noindex>.<\/p>\n

Kui kirjutate Java keeles, siis m\u00e4\u00e4rake privaatsetele meetoditele ja muutujatele vaikimisi private<\/a><\/noindex>.<\/p>\n

Avatuse\/suletuse p\u00f5him\u00f5te<\/h3>\n

\nSeda p\u00f5him\u00f5tet on lihtne meeles pidada, lugedes j\u00e4rgmist v\u00e4idet: \"Tarkvarased \u00fcksused (klassid, moodulid, funktsioonid jne) peaksid olema avatud laiendamiseks, kuid suletud muutmiseks\". Praktikas t\u00e4hendab see, et nad v\u00f5ivad v\u00f5imaldada oma k\u00e4itumise muutmist ilma algkoodi muutmiseta.<\/p>\n

P\u00f5him\u00f5te on oluline, kui algkodi muutmine n\u00f5uab selle \u00fclevaatamist, moodulitestimist ja muid menetlusi. Kood, mis j\u00e4rgib avatuse\/suletuse p\u00f5him\u00f5tet, ei muutu laiendamisel, seega on selle kasutamisel m\u00e4rgatavalt v\u00e4hem probleeme.<\/p>\n

Siin on kood, mis rikub seda p\u00f5him\u00f5tet.<\/p>\n

\"10
\n
\nKui on vaja midagi muuta, v\u00f5tab see palju aega, kuna tuleb muuta k\u00f5iki koodil\u00f5ike, mis on seotud vajaliku fragmentiga.<\/p>\n

Muide, avatus-sulgumine on \u00fcks SOLID-i p\u00f5him\u00f5tteid.<\/p>\n

\u00dcksikule vastutusele vastav p\u00f5him\u00f5te (SRP)<\/h3>\n

\nVeel \u00fcks p\u00f5him\u00f5te SOLID-i kogumist. See \u00fctleb, et \"klassil on vaid \u00fcks p\u00f5hjus, miks seda muuta\". Klass t\u00e4idab ainult \u00fchte \u00fclesannet. Tal v\u00f5ivad olla mitmed meetodid, kuid iga\u00fcht kasutatakse \u00fcksnes \u00fcldise \u00fclesande lahendamiseks. K\u00f5ik meetodid ja omadused peavad teenima ainult seda. <\/p>\n

\"10
\n
\nSelle p\u00f5him\u00f5tte v\u00e4\u00e4rtus seisneb selles, et see n\u00f5rgendab seoseid eraldi tarkvarakomponentide ja koodi vahel. Kui klassis saada rohkem kui \u00fcks funktsionaalsus, tekitab see seose kahe funktsiooni vahel. Nii et kui \u00fcht neist muuta, on suur t\u00f5en\u00e4osus, et rikkuda teist, mis on esimesele seotud. See t\u00e4hendab testimists\u00fcklite arvu suurenemist, et tuvastada k\u00f5ik probleemid eelnevalt.<\/p>\n

S\u00f5ltuvuste p\u00f6\u00f6ramise p\u00f5him\u00f5te (DIP)<\/h3>\n

\n\"10
\n
\n\u00dclaltoodud koodin\u00e4ide, kus AppManager s\u00f5ltub EventLogWriter'ist, mis on omakorda tihedalt seotud AppManageriga. Kui on vaja teist viisi teavitamiseks, olgu see siis push, SMS v\u00f5i e-mail, tuleb muuta klassi AppManager.<\/p>\n

Probleemi saab lahendada DIP abil. Seega, selle asemel, et k\u00fcsida AppManagerilt, k\u00fcsime EventLogWriter'ilt, mis viiakse ellu raamistikuga.<\/p>\n

DIP v\u00f5imaldab h\u00f5lpsasti asendada \u00fcksikuid mooduleid teistega, muutes s\u00f5ltuvuse moodulit. See v\u00f5imaldab muuta \u00fchte moodulit, m\u00f5jutamata teisi.<\/p>\n

Koostamine, mitte p\u00e4rimine<\/h3>\n

\n\"10Peamised viisid koodi taaskasutamiseks on p\u00e4rimine ja koostamine, kummalgi on oma eelised ja puudused. Tavaliselt eelistatakse teist, kuna see on paindlikum.<\/p>\n

Koostamine v\u00f5imaldab klassi k\u00e4itumist muuta k\u00e4itamise ajal, seadistades selle omadusi. Interfaiside rakendamisel kasutatakse pol\u00fcmorfismi, mis annab paindlikuma rakenduse.<\/p>\n

Isegi Joshua Bloch \"Effective Java\"-s soovitab eelistada koostamist mitte p\u00e4rimist.<\/p>\n

Barbara Liskovi asendusp\u00f5him\u00f5te (LSP)<\/h3>\n

\nVeel \u00fcks SOLID t\u00f6\u00f6riistade p\u00f5him\u00f5te. See \u00fctleb, et alamt\u00fc\u00fcbid peavad olema asendatavad supert\u00fc\u00fcbiga. See t\u00e4hendab, et meetodid ja funktsioonid, mis t\u00f6\u00f6tavad superklassiga, peavad saama probleemideta t\u00f6\u00f6tada ka selle alams klassidega.<\/p>\n

LSP on seotud nii \u00fche vastutuse p\u00f5him\u00f5tte kui ka vastutuse jagamise p\u00f5him\u00f5ttega. Kui klass pakub rohkem funktsionaalsust kui alams klass, siis viimane ei toeta m\u00f5ningaid funktsioone, rikkudes sellega seda p\u00f5him\u00f5tet.<\/p>\n

Siin on koodil\u00f5ik, mis rikub LSP-d.<\/p>\n

\"10
\n
\nMeetod area(Rectangle r) arvutab nelinurga pindala. Programm eba\u00f5nnestub p\u00e4rast Square'i t\u00e4itmist, kuna Square ei ole siin nelinurk. Vastavalt LSP p\u00f5him\u00f5ttele peavad funktsioonid, mis kasutavad p\u00f5hiklassi viiteid, olema v\u00f5imelised kasutama ka tuletatud klasside objekte ilma lisainstruktsioonideta.<\/p>\n

See p\u00f5him\u00f5te, mis on alamt\u00fc\u00fcbi spetsiifiline m\u00e4\u00e4ratlemine, pakkus v\u00e4lja Barbara Liskov 1987. aastal konverentsil, kus tema peaettekanne oli 'Andmete abstraktsioon ja hierarhia' \u2014 seet\u00f5ttu see nime saanud.<\/p>\n

Liidese jagamise p\u00f5him\u00f5te (ISP)<\/h3>\n

\nJ\u00e4lle \u00fcks SOLID p\u00f5him\u00f5te. Selle kohaselt ei tohi liidest, mida ei kasutata, rakendada. Selle p\u00f5him\u00f5tte j\u00e4rgimine aitab s\u00fcsteemil j\u00e4\u00e4da paindlikuks ja reguleeritavaks, kui muudetakse t\u00f6\u00f6loogikat.<\/p>\n

Seda olukorda esineb k\u00f5ige sagedamini, kui liides sisaldab mitut funktsionaalsust, kusjuures kliendile on vajalik ainult \u00fcks neist.<\/p>\n

Kuna liidese kirjutamine on keeruline \u00fclesanne, on p\u00e4rast t\u00f6\u00f6 l\u00f5petamist sellele muutmine, rikkumata midagi, probleem.<\/p>\n

ISP p\u00f5him\u00f5tte eelis Java-s on see, et esmalt peate rakendama k\u00f5ik meetodid ja alles siis saavad neid kasutada klassid. Seet\u00f5ttu annab p\u00f5him\u00f5te v\u00f5imaluse v\u00e4hendada meetodite arvu.<\/p>\n

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

Programmeerimine liidese, mitte rakenduse j\u00e4rgi<\/h3>\n

\nSiit on k\u00f5ik arusaadav nime j\u00e4rgi. Selle p\u00f5him\u00f5tte rakendamine toob kaasa paindliku koodi loomise, mis suudab t\u00f6\u00f6tada igasuguste uute liidese rakendustega.<\/p>\n

Tuleb kasutada liidese t\u00fc\u00fcpi muutujaid, tagastatavaid t\u00fc\u00fcpe v\u00f5i meetodi argumentide t\u00fc\u00fcpe. N\u00e4ide \u2014 kasutamine SuperClass'i asemel SubClass'i.<\/p>\n

Kusjuures:<\/p>\n

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

Ja mitte:<\/p>\n

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

Siin on praktiline rakendus sellest, millest eelnevalt r\u00e4\u00e4giti.<\/p>\n

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

Delegatsiooni p\u00f5him\u00f5te<\/h3>\n

\nLevinud n\u00e4ide on meetodid equals() ja hashCode() Java-s. Kui tuleb v\u00f5rrelda kaht objekti, delegeeritakse see toiming vastavale klassile, mitte kliendile.<\/p>\n

P\u00f5him\u00f5tte eelisteks on koodi dubleerimise v\u00e4ltimine ja suhteliselt lihtne k\u00e4itumise muutmine. Samuti on see rakendatav s\u00fcndmuste delegeerimiseks.<\/p>\n

\"10
\n
\nK\u00f5ik need p\u00f5him\u00f5tted v\u00f5imaldavad kirjutada paindlikumat, ilusamat ja usaldusv\u00e4\u00e4rsemat koodi, millel on k\u00f5rge seos ja madal sidusus. Loomulikult on teooria tore, kuid et arendaja hakkaks t\u00f5eliselt kasutama omandatud teadmisi, on vajalik praktika. J\u00e4rgmine samm p\u00e4rast OOP p\u00f5him\u00f5tete omandamist v\u00f5ib olla tarkvaraarenduse levinud probleemide lahendamiseks m\u00f5eldud disainimustrite uurimine.<\/p>\n

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