{"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\/sv\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principer f\u00f6r objektorienterad programmering som varje utvecklare b\u00f6r veta","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nJag st\u00f6ter ganska ofta p\u00e5 utvecklare som inte har h\u00f6rt talas om SOLID-principerna (vi ber\u00e4ttade detaljerat om dem h\u00e4r<\/a><\/noindex>. \u2014 Anm.) eller objektorienterad programmering (OOP), eller har h\u00f6rt talas om dem men inte anv\u00e4nder dem i praktiken. I den h\u00e4r artikeln beskrivs f\u00f6rdelarna med OOP-principerna som hj\u00e4lper utvecklare i deras dagliga arbete. Vissa av dem \u00e4r v\u00e4lk\u00e4nda, andra \u00e4r mindre k\u00e4nda, s\u00e5 artikeln kommer att vara anv\u00e4ndbar b\u00e5de f\u00f6r nyb\u00f6rjare och erfarna programmerare.
\n<\/a><\/noindex><\/p>\n

P\u00e5minnelse:<\/b> Till alla l\u00e4sare av \"Habr\" \u2014 rabatt p\u00e5 10 000 rubel vid registrering till vilken kurs som helst p\u00e5 Skillbox med rabattkoden \"Habr\".<\/i><\/p>\n

Skillbox rekommenderar:<\/b> Utbildningskurs online Java-utvecklare<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

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

\nEn ganska enkel princip, vars inneb\u00f6rd framg\u00e5r av namnet: \"Upprepa dig inte\". F\u00f6r en programmerare inneb\u00e4r detta att undvika duplicerad kod samt m\u00f6jligheten att anv\u00e4nda abstraktion i sitt arbete.<\/p>\n

Om det finns tv\u00e5 upprepande sektioner i koden, b\u00f6r de sl\u00e5s samman till en metod. Om ett fast v\u00e4rde anv\u00e4nds mer \u00e4n en g\u00e5ng, b\u00f6r det omvandlas till en offentlig konstant.<\/p>\n

Detta g\u00f6rs f\u00f6r att f\u00f6renkla koden och g\u00f6ra dess underh\u00e5ll enklare, vilket \u00e4r syftet med OOP. Man b\u00f6r dock inte missbruka sammanslagning, eftersom samma kod inte klarar tester b\u00e5de med OrderId och med SSN.<\/p>\n

Inkapself\u00f6r\u00e4ndringar<\/h3>\n

\nProgramvaruprodukterna hos de flesta f\u00f6retag utvecklas st\u00e4ndigt. Det inneb\u00e4r att koden m\u00e5ste \u00e4ndras och st\u00f6djas. Man kan f\u00f6renkla sitt liv genom inkapsling. Detta g\u00f6r det m\u00f6jligt att testa och underh\u00e5lla den befintliga kodbasen mer effektivt. H\u00e4r \u00e4r ett av exemplen<\/a><\/noindex>.<\/p>\n

Om du skriver i Java, ska du som standard tilldela private till metoder och variabler<\/a><\/noindex>.<\/p>\n

\u00d6ppen\/st\u00e4ngd princip<\/h3>\n

\nDenna princip \u00e4r l\u00e4tt att komma ih\u00e5g genom att l\u00e4sa f\u00f6ljande uttalande: \"Programvaruenheter (klasser, moduler, funktioner etc.) b\u00f6r vara \u00f6ppna f\u00f6r utvidgning men st\u00e4ngda f\u00f6r f\u00f6r\u00e4ndring\". I praktiken inneb\u00e4r detta att de kan till\u00e5ta att deras beteende \u00e4ndras utan att \u00e4ndra k\u00e4llkoden.<\/p>\n

Principen \u00e4r viktig n\u00e4r f\u00f6r\u00e4ndringar i k\u00e4llkoden kr\u00e4ver att den granskas, genomg\u00e5r enhetstestning och andra procedurer. Kod som f\u00f6ljer den \u00f6ppna\/st\u00e4ngda principen \u00e4ndras inte vid utvidgning, vilket g\u00f6r att man f\u00e5r f\u00e4rre problem med den.<\/p>\n

H\u00e4r \u00e4r ett kodexempel som bryter mot denna princip.<\/p>\n

\"10
\n
\nOm det beh\u00f6vs n\u00e5gra \u00e4ndringar i den, kommer det att ta mycket tid eftersom alla kodavsnitt som har kopplingar till det n\u00f6dv\u00e4ndiga fragmentet m\u00e5ste \u00e4ndras.<\/p>\n

F\u00f6rresten, \u00f6ppenhet-st\u00e4ngdhet \u00e4r en av principerna i SOLID.<\/p>\n

Principen om enskild ansvarighet (SRP)<\/h3>\n

\nEn annan princip fr\u00e5n SOLID-setet. Den s\u00e4ger att \"det finns bara en anledning till att en klass kan \u00e4ndras\". En klass l\u00f6ser bara en uppgift. Den kan ha flera metoder, men var och en av dem anv\u00e4nds endast f\u00f6r att l\u00f6sa den \u00f6vergripande uppgiften. Alla metoder och egenskaper ska endast tj\u00e4na detta syfte. <\/p>\n

\"10
\n
\nV\u00e4rdet av denna princip \u00e4r att den minskar kopplingen mellan enskilda mjukvarukomponenter och koden. Om man l\u00e4gger till mer \u00e4n en funktionalitet i en klass, introducerar det en koppling mellan tv\u00e5 funktioner. S\u00e5ledes, om man \u00e4ndrar en av dem, finns det stor risk att f\u00f6rst\u00f6ra den andra, som \u00e4r kopplad till den f\u00f6rsta. Det inneb\u00e4r en \u00f6kning av testcykler f\u00f6r att uppt\u00e4cka alla problem i f\u00f6rv\u00e4g.<\/p>\n

Principen om beroendeinversion (DIP)<\/h3>\n

\n\"10
\n
\nExemplet ovan visar koden d\u00e4r AppManager \u00e4r beroende av EventLogWriter, som i sin tur \u00e4r n\u00e4ra kopplad till AppManager. Om ett annat s\u00e4tt beh\u00f6vs f\u00f6r att visa en avisering, vare sig det \u00e4r en push, SMS eller e-post, m\u00e5ste klassen AppManager \u00e4ndras.<\/p>\n

Problemet kan l\u00f6sas med hj\u00e4lp av DIP. Ist\u00e4llet f\u00f6r AppManager, beg\u00e4r vi EventLogWriter, som kommer att introduceras genom ramverket.<\/p>\n

DIP g\u00f6r det m\u00f6jligt att problemfritt byta ut enskilda moduler mot andra, genom att \u00e4ndra beroendemodulen. Det g\u00f6r det m\u00f6jligt att \u00e4ndra en modul utan att p\u00e5verka de andra.<\/p>\n

Komposition ist\u00e4llet f\u00f6r arv<\/h3>\n

\n\"10De tv\u00e5 huvudmetoderna f\u00f6r att \u00e5teranv\u00e4nda kod \u00e4r arv och komposition, och b\u00e5da har sina f\u00f6rdelar och nackdelar. Vanligtvis f\u00f6redras den andra eftersom den \u00e4r mer flexibel.<\/p>\n

Komposition m\u00f6jligg\u00f6r f\u00f6r\u00e4ndring av klassens beteende under k\u00f6rning genom att st\u00e4lla in dess egenskaper. Vid implementering av gr\u00e4nssnitt anv\u00e4nds polymorfism, vilket ger en mer flexibel implementation.<\/p>\n

\u00c4ven \"Effective Java\" av Joshua Bloch rekommenderar att man f\u00f6redrar komposition framf\u00f6r arv.<\/p>\n

Principen om Barbara Liskovs substitutionsprincip (LSP)<\/h3>\n

\n\u00c4nnu en princip fr\u00e5n SOLID-verktygen. Den s\u00e4ger att underklasser ska kunna ers\u00e4tta sin superklass. Det vill s\u00e4ga metoder och funktioner som arbetar med superklassen m\u00e5ste kunna fungera utan problem med dess underklasser.<\/p>\n

LSP \u00e4r kopplad b\u00e5de till principen om enhetligt ansvar och principiell delning av ansvar. Om en klass erbjuder mer funktionalitet \u00e4n en underklass, kommer den senare inte att st\u00f6dja vissa funktioner, vilket bryter mot denna princip.<\/p>\n

H\u00e4r \u00e4r en kodsnutt som bryter mot LSP.<\/p>\n

\"10
\n
\nMetoden area(Rectangle r) ber\u00e4knar arean av Rectangle. Programmet kommer att krascha efter att ha k\u00f6rt Square, eftersom Square h\u00e4r inte \u00e4r en Rectangle. Enligt principen LSP b\u00f6r funktioner som anv\u00e4nder referenser till bas-klasser kunna anv\u00e4nda \u00e4ven objekt av underklasser utan ytterligare instruktioner.<\/p>\n

Denna princip, som \u00e4r en specifik definition av underklass, f\u00f6reslogs av Barbara Liskov 1987 vid en konferens d\u00e4r hon h\u00e5llit en huvudf\u00f6rel\u00e4sning med titeln \"Databasfr\u00e5gor och hierarkier\" - d\u00e4rav namnet.<\/p>\n

Principen om interface-separation (ISP)<\/h3>\n

\nYtterligare en princip fr\u00e5n SOLID. Enligt den b\u00f6r ett interface som inte anv\u00e4nds inte implementeras. Att f\u00f6lja denna princip hj\u00e4lper systemet att f\u00f6rbli flexibelt och redo f\u00f6r refactoring n\u00e4r f\u00f6r\u00e4ndringar g\u00f6rs i logiken.<\/p>\n

Denna situation uppst\u00e5r ofta n\u00e4r ett interface inneh\u00e5ller flera funktionaliteter, men kunden beh\u00f6ver bara en av dem.<\/p>\n

Eftersom det \u00e4r en komplex uppgift att skriva ett interface, kommer det att bli problematiskt att \u00e4ndra det efter att det slutf\u00f6rts utan att bryta n\u00e5got.<\/p>\n

En f\u00f6rdel med ISP-principen i Java \u00e4r att man f\u00f6rst m\u00e5ste implementera alla metoder, och f\u00f6rst d\u00e4refter kan de anv\u00e4ndas av klasser. D\u00e4rf\u00f6r ger principen m\u00f6jlighet att minska antalet metoder.<\/p>\n

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

Programmering f\u00f6r interface, inte implementation<\/h3>\n

\nH\u00e4r \u00e4r det tydligt fr\u00e5n namnet. Till\u00e4mpningen av denna princip leder till skapandet av flexibel kod som kan fungera med vilken ny implementation av ett interface som helst.<\/p>\n

Man b\u00f6r anv\u00e4nda interface-typ f\u00f6r variabler, returtyper eller argumenttyp i metoden. Exempel \u2014 anv\u00e4ndning av SuperClass ist\u00e4llet f\u00f6r SubClass.<\/p>\n

Det vill s\u00e4ga:<\/p>\n

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

Och inte:<\/p>\n

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

H\u00e4r \u00e4r en praktisk implementation av det som n\u00e4mnts ovan.<\/p>\n

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

Delegationsprincipen<\/h3>\n

\nEtt vanligt exempel \u00e4r metoderna equals() och hashCode() i Java. N\u00e4r tv\u00e5 objekt ska j\u00e4mf\u00f6ras, delegeras denna \u00e5tg\u00e4rd till den aktuella klassen ist\u00e4llet f\u00f6r klienten.<\/p>\n

F\u00f6rdelen med principen \u00e4r avsaknaden av kodduplicering och relativt enkel f\u00f6r\u00e4ndring av beteende. Den \u00e4r ocks\u00e5 till\u00e4mpbar p\u00e5 h\u00e4ndelsedelegation.<\/p>\n

\"10
\n
\nAlla dessa principer g\u00f6r det m\u00f6jligt att skriva mer flexibel, vacker och p\u00e5litlig kod med h\u00f6g koppling och l\u00e5g beroende. Sj\u00e4lvklart \u00e4r teorin bra, men f\u00f6r att utvecklaren verkligen ska b\u00f6rja anv\u00e4nda de f\u00f6rv\u00e4rvade kunskaperna, beh\u00f6vs praktik. N\u00e4sta steg efter att ha beh\u00e4rskat OOP-principerna kan vara att studera designm\u00f6nster f\u00f6r att l\u00f6sa vanliga problem inom mjukvaruutveckling.<\/p>\n

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