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

\"10
\n
\nMul puutun sageli kokku arendajatega, kes ei ole kuulnud SOLID p\u00f5him\u00f5tetest (me oleme nendest siin p\u00f5hjalikult r\u00e4\u00e4kinud<\/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 igap\u00e4evases t\u00f6\u00f6s. M\u00f5ned neist on h\u00e4sti tuntud, teised mitte niiv\u00f5rd, seega on artikkel kasulik nii algajatele kui ka kogenud programmeerijatele.
\n<\/a><\/noindex><\/p>\n

Tuletame meelde:<\/b> k\u00f5igile \u00abHabr\u00bb lugejatele \u2014 10 000 rubla allahindlus k\u00f5ikide Skillboxi kursuste registreerimisel sooduskoodiga \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox soovitab:<\/b> Hariduslik veebikursus \u00abJava-arendaja\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

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

\nSuhteliselt lihtne p\u00f5him\u00f5te, mille sisu on arusaadav pealkirjast: \u00ab\u00c4ra korruta end\u00bb. Arendaja jaoks t\u00e4hendab see vajadust v\u00e4ltida dubleerivat koodi ning v\u00f5imalust kasutada t\u00f6\u00f6s abstraktsiooni.<\/p>\n

Kui koodis on kaks korduvat l\u00f5iku, tuleks need liita \u00fchte meetodisse. Kui fikseeritud v\u00e4\u00e4rtust kasutatakse rohkem kui \u00fcks kord, tasub see \u00fcmber kujundada avalikuks konstandiks.<\/p>\n

See on vajalik koodi lihtsustamiseks ja selle haldamise h\u00f5lbustamiseks, mis on OOP peamine eesm\u00e4rk. Liialdada liitmisega ei tasu, kuna sama kood ei saa samaaegselt l\u00e4bida kontrolli nii OrderId kui ka SSN puhul.<\/p>\n

Kasutusekspressimise muutmine<\/h3>\n

\nEnamik ettev\u00f5tete tarkvaratooteid areneb pidevalt. See t\u00e4hendab, et koodis tuleb teha muudatusi, seda tuleb toetada. Enda elu lihtsustamiseks v\u00f5ib kasutada kapseldamist. See v\u00f5imaldab olemasolevat koodibaasi t\u00f5husamalt testida ja hallata. Siin on \u00fcks n\u00e4ide<\/a><\/noindex>.<\/p>\n

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

Ava\/aitama printsiip<\/h3>\n

\nSelle printsiibi saab kergesti meelde j\u00e4tta, lugedes j\u00e4rgmist v\u00e4idet: \"Tarkvara \u00fcksused (klassid, moodulid, funktsioonid jne) peaksid olema avatud laiendamiseks, kuid suletud muutmiseks\". Praktikas t\u00e4hendab see, et nad v\u00f5imaldavad oma k\u00e4itumise muutmist ilma algkoodi muutmata.<\/p>\n

P\u00f5him\u00f5te on oluline, kui l\u00e4htekoodi muudatused n\u00f5uavad selle \u00fclevaatamist, modulaarset testimist ja muid protseduure. Kood, mis j\u00e4rgib avatud\/suletud p\u00f5him\u00f5tet, ei muutu laiendamise korral, mist\u00f5ttu on sellega palju v\u00e4hem probleeme.<\/p>\n

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

\"10
\n
\nKui sellega midagi muuta on vaja, v\u00f5tab see palju aega, kuna tuleb muuta k\u00f5iki koodi osi, millel on seos vajaliku fragmentiga.<\/p>\n

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

\u00dche vastutuse p\u00f5him\u00f5te (SRP)<\/h3>\n

\nVeel \u00fcks p\u00f5him\u00f5te SOLID-i kogumikust. See \u00fctleb, et \"on ainult \u00fcks p\u00f5hjus, mis viib klassi muutmiseni\". Klass lahendab ainult \u00fche \u00fclesande. Sellel v\u00f5ivad olla mitu meetodit, kuid iga\u00fcht kasutatakse ainult \u00fcldise \u00fclesande lahendamiseks. K\u00f5ik meetodid ja omadused peavad teenima vaid seda. <\/p>\n

\"10
\n
\nSelle printsiibi v\u00e4\u00e4rtus seisneb selles, et see n\u00f5rgendab seoseid tarkvarakomponentide ja koodi vahel. Kui klassi lisada rohkem kui \u00fcks funktsionaalsus, tekib side kahe funktsiooni vahel. Seega, kui muuta \u00fchte neist, on suur oht h\u00e4irida teist, mis on esimesele seotud. See t\u00e4hendab, et testimise ts\u00fcklite arvu suurenemine on vajalik, et varakult k\u00f5iki probleeme avastada.<\/p>\n

S\u00f5ltuvuste inverteerimise printsiip (DIP)<\/h3>\n

\n\"10
\n
\n\u00dclaltoodud koodin\u00e4ites s\u00f5ltub AppManager EventLogWriteri klasist, mis omakorda on tihedalt seotud AppManageriga. Kui on vaja muud viisi teate edastamiseks, olgu see siis push, SMS v\u00f5i e-kiri, tuleb AppManageri klassi muuta.<\/p>\n

Probleem saab DIP-i abil lahendatud. Nii et parema l\u00e4henemise asemel k\u00fcsime EventLogWriterit, mis tuuakse sisse raamistiku kaudu.<\/p>\n

DIP v\u00f5imaldab h\u00f5lpsasti asendada eraldi mooduleid teistega, muutes s\u00f5ltuvusmooduli. See annab v\u00f5imaluse muuta \u00fcht moodulit, m\u00f5jutamata teisi.<\/p>\n

Kompositsioon asemel p\u00e4rimine<\/h3>\n

\n\"10Koodi taaskasutamise p\u00f5himeetodeid on kaks: p\u00e4rimine ja kompositsioon, millest kummalgi on omad eelised ja puudused. \u00dcldiselt eelistatakse teist, kuna see on paindlikum.<\/p>\n

Kompositsioon v\u00f5imaldab muuta klassi k\u00e4itumist k\u00e4itamise ajal, seadistades selle omadused. Liideste rakendamisel kasutatakse pol\u00fcmorfismi, mis v\u00f5imaldab paindlikumat rakendust.<\/p>\n

Ieven 'Effective Java' autor Joshua Bloch soovitab eelistada kompositsiooni, mitte p\u00e4rimist.<\/p>\n

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

\nVeel \u00fcks p\u00f5him\u00f5te SOLID-mudelist. See \u00fctleb, et alamklassid peavad olema asendatavad superklassiga. See t\u00e4hendab, et meetodid ja funktsioonid, mis t\u00f6\u00f6tavad superklassiga, peavad olema sujuvalt kohandatavad ka alamklasside jaoks.<\/p>\n

LSP on seotud nii \u00fchte vastutust kui ka vastutuse jagamise p\u00f5him\u00f5ttega. Kui klass annab rohkem funktsionaalsust kui alamklass, siis viimane ei toeta teatud funktsioone, rikkudes seet\u00f5ttu seda p\u00f5him\u00f5tet.<\/p>\n

Siin on koodil\u00f5ik, mis on LSP-ga vastuolus.<\/p>\n

\"10
\n
\nMeetod area(Rectangle r) arvutab Ristk\u00fcliku pindala. Programm kukub p\u00e4rast Square'i t\u00e4itmist, kuna Square ei ole siin Ristk\u00fclik. Vastavalt LSP p\u00f5him\u00f5ttele peaksid funktsioonid, mis kasutavad aluseks olevaid klasse, olema v\u00f5imelised kasutama ka tuletatud klasside objekte ilma lisainstruktsioonideta.<\/p>\n

See p\u00f5him\u00f5te, mis on spetsiifiline alamliigi m\u00e4\u00e4ratlemiseks, esitas Barbara Liskov 1987. aastal konverentsil oma peamisel ettekandel, mille pealkiri oli \u201eAndmete abstraktsioon ja hierarhia\u201c \u2014 seet\u00f5ttu ka selle nimi.<\/p>\n

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

\nVeel \u00fcks SOLID p\u00f5him\u00f5te. Selle kohaselt ei peaks liidest, mida ei kasutata, rakendama. Selle p\u00f5him\u00f5tte j\u00e4rgimine aitab s\u00fcsteemil j\u00e4\u00e4da paindlikuks ja muudatuste tegemisel refaktooritavaks.<\/p>\n

Seda olukorda esineb k\u00f5ige sagedamini siis, kui liides sisaldab mitmeid funktsionaalsusi, samas kui kliendi jaoks on vajalik vaid \u00fcks neist.<\/p>\n

Kuna liidese kirjutamine on keeruline \u00fclesanne, on selle muutmine p\u00e4rast selle l\u00f5ppemist probleem, mida ei tohiks rikkuda.<\/p>\n

ISP printsiip Java's annab selle, et k\u00f5ik meetodid tuleb esmalt rakendada ja alles seej\u00e4rel saavad klassid neid kasutada. Seet\u00f5ttu v\u00f5imaldab printsiip v\u00e4hendada meetodite arvu.<\/p>\n

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

Programmeerige liidese, mitte rakenduse jaoks<\/h3>\n

\nSiit on k\u00f5ik selge juba pealkirjast. Selle printsiibi rakendamine viib paindliku koodi loomise, mis suudab t\u00f6\u00f6tada iga uue liidese rakendusega.<\/p>\n

Tuleb kasutada liidese t\u00fc\u00fcpi muutujaid, tagastatavaid t\u00fc\u00fcpe v\u00f5i meetodi argumendi t\u00fc\u00fcpi. N\u00e4ide - kasutage SuperClass'i, mitte SubClass'i.<\/p>\n

\u00dcks s\u00f5na:<\/p>\n

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

Ja mitte:<\/p>\n

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

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

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

Delegeerimise printsiip<\/h3>\n

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

Printsiibi eeliseks on koodi dubleerimise puudumine ja suhteliselt lihtne k\u00e4itumise muutmine. Samuti on see rakendatav s\u00fcndmuste delegeerimisele.<\/p>\n

\"10
\n
\nK\u00f5ik need p\u00f5him\u00f5tted v\u00f5imaldavad kirjutada paindlikumat, ilusamat ja usaldusv\u00e4\u00e4rsemat koodi, millel on k\u00f5rge seotuse ja madala sidumise tase. Loomulikult on teooria tore, kuid et arendaja t\u00f5esti omandatud teadmisi rakendaks, on vajalik praktika. J\u00e4rgmine samm p\u00e4rast OOP p\u00f5him\u00f5tete omandamist v\u00f5iks olla disainimustrite uurimine, et lahendada \u00fcldisi tarkvaraarenduse probleeme.<\/p>\n

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