{"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\/da\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principper for objektorienteret programmering, som hver udvikler skal kende.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nJeg m\u00f8der ofte udviklere, som ikke har h\u00f8rt om SOLID-principperne (vi har tidligere skrevet om dem her<\/a><\/noindex>. \u2014 red.) eller om objektorienteret programmering (OOP), eller som har h\u00f8rt om det, men ikke anvender det i praksis. I denne artikel beskrives fordelene ved OOP-principper, som hj\u00e6lper udviklere i deres daglige arbejde. Nogle er velkendte, andre mindre s\u00e5, s\u00e5 artiklen vil v\u00e6re nyttig for b\u00e5de begyndere og erfarne programm\u00f8rer.
\n<\/a><\/noindex><\/p>\n

Vi minder om:<\/b> for alle l\u00e6sere af \u00abHabr\u00bb \u2014 rabat p\u00e5 10.000 rubler ved tilmelding til ethvert Skillbox-kursus med rabatkoden \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox anbefaler:<\/b> Online uddannelseskursus \u00abJava-udvikler\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

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

\nEt ret simpelt princip, hvis essens er klar fra navnet: \u00abGentag dig ikke\u00bb. For programm\u00f8rer betyder det n\u00f8dvendigheden af at undg\u00e5 duplikeret kode samt muligheden for at anvende abstraktion i arbejdet.<\/p>\n

Hvis der er to gentagne sektioner i koden, b\u00f8r de kombineres til en metode. Hvis en fastv\u00e6rdi bruges mere end \u00e9n gang, er det en god ide at omdanne den til en global konstant.<\/p>\n

Dette er n\u00f8dvendigt for at forenkle koden og g\u00f8re dens vedligeholdelse lettere, hvilket er det prim\u00e6re m\u00e5l med OOP. Misbrug ikke sammenl\u00e6gning, da den samme kode ikke vil best\u00e5 pr\u00f8ven som OrderId og SSN.<\/p>\n

Indkapsling af \u00e6ndringer<\/h3>\n

\nSoftwareprodukter fra de fleste virksomheder udvikler sig konstant. Dette betyder, at koden skal \u00e6ndres og vedligeholdes. Man kan forenkle livet ved hj\u00e6lp af indkapsling. Dette muligg\u00f8r mere effektiv testning og vedligeholdelse af den eksisterende kodebase. Her er et eksempel<\/a><\/noindex>.<\/p>\n

Hvis du skriver i Java, s\u00e5 tildel som standard private til metoder og variabler<\/a><\/noindex>.<\/p>\n

\u00c5benhed\/lukkethed-princippet<\/h3>\n

\nDette princip kan nemt huskes ved at l\u00e6se f\u00f8lgende udsagn: \u00abSoftwareenheder (klasser, moduler, funktioner osv.) skal v\u00e6re \u00e5bne for udvidelse, men lukkede for \u00e6ndringer\u00bb. I praksis betyder det, at de kan tillade \u00e6ndring af adf\u00e6rd uden at \u00e6ndre den oprindelige kildekode.<\/p>\n

Princippet er vigtigt, n\u00e5r \u00e6ndringer i kildekoden kr\u00e6ver en gennemgang, modultestning og andre procedurer. Koden, der f\u00f8lger princippet om \u00e5benhed\/lukkethed, \u00e6ndres ikke ved udvidelse, hvilket betyder, at der er langt f\u00e6rre problemer med den.<\/p>\n

Her er et eksempel p\u00e5 kode, der overtr\u00e6der dette princip.<\/p>\n

\"10
\n
\nHvis der er behov for at \u00e6ndre noget i den, vil det tage meget tid, fordi man skal \u00e6ndre alle dele af koden, der har forbindelse til det relevante fragment.<\/p>\n

Forresten er \u00e5benhed-lukkethed et af SOLID-principperne.<\/p>\n

Princippet om enkelt ansvar (SRP)<\/h3>\n

\nEndnu et princip fra SOLID-panelet. Det siger, at \"der kun findes \u00e9n \u00e5rsag til at \u00e6ndre en klasse\". En klasse l\u00f8ser kun \u00e9n opgave. Den kan have flere metoder, men hver af dem bruges kun til at l\u00f8se den overordnede opgave. Alle metoder og egenskaber skal kun tjene dette form\u00e5l. <\/p>\n

\"10
\n
\nV\u00e6rdien af dette princip er, at det sv\u00e6kker forbindelsen mellem den enkelte softwarekomponent og koden. Hvis der tilf\u00f8jes mere end \u00e9n funktionalitet til en klasse, indf\u00f8rer det forbindelse mellem to funktioner. S\u00e5ledes, hvis man \u00e6ndrer en af dem, er der en stor risiko for at \u00f8del\u00e6gge den anden, der er relateret til den f\u00f8rste. Dette betyder en \u00f8get testcyklus for at opdage alle problemer p\u00e5 forh\u00e5nd.<\/p>\n

Princippet om afh\u00e6ngighedsinversion (DIP)<\/h3>\n

\n\"10
\n
\nOvenst\u00e5ende er et eksempel p\u00e5 kode, hvor AppManager er afh\u00e6ngig af EventLogWriter, som igen er t\u00e6t knyttet til AppManager. Hvis man har brug for en anden m\u00e5de at vise notifikationer p\u00e5, hvad enten det er push, SMS eller e-mail, skal man \u00e6ndre AppManager-klassen.<\/p>\n

Problemet kan l\u00f8ses ved hj\u00e6lp af DIP. S\u00e5 i stedet for AppManager anmoder vi EventLogWriter, som vil blive indf\u00f8rt ved hj\u00e6lp af rammev\u00e6rket.<\/p>\n

DIP giver mulighed for uden problemer at udskifte individuelle moduler med andre ved at \u00e6ndre afh\u00e6ngighedsmodulet. Dette giver mulighed for at \u00e6ndre et modul uden at p\u00e5virke de andre.<\/p>\n

Komposition frem for arv<\/h3>\n

\n\"10Der er to prim\u00e6re metoder til genbrug af kode \u2014 arv og komposition, hvor hver har sine fordele og ulemper. Som regel gives der pr\u00e6ference til den anden, da den er mere fleksibel.<\/p>\n

Kompositionen giver mulighed for at \u00e6ndre klassens adf\u00e6rd under k\u00f8rslen ved at indstille dens egenskaber. N\u00e5r man implementerer gr\u00e6nseflader, anvendes polymorfi, hvilket giver en mere fleksibel implementering.<\/p>\n

Selv \u201cEffective Java\u201d af Joshua Bloch anbefaler at foretr\u00e6kke komposition frem for arv.<\/p>\n

Barbara Lisks substitutionsprincip (LSP)<\/h3>\n

\nEndnu et princip fra SOLID-v\u00e6rkt\u00f8jskassen. Det siger, at subtyper skal kunne udskiftes med supertypen. Det vil sige, at metoder og funktioner, som arbejder med superklassen, skal kunne arbejde problemfrit med dens underklasser.<\/p>\n

LSP er relateret til b\u00e5de princippet om enkeltst\u00e5ende ansvar og princippet om ansvarssplit. Hvis en klasse giver mere funktionalitet end en underklasse, vil den sidstn\u00e6vnte ikke underst\u00f8tte nogle funktioner, hvilket bryder dette princip.<\/p>\n

Her er et stykke kode, der strider imod LSP.<\/p>\n

\"10
\n
\nMetoden area(Rectangle r) beregner arealet af Rectangle. Programmet vil fejle efter udf\u00f8relsen af Square, da Square her ikke er en Rectangle. If\u00f8lge LSP skal funktioner, der bruger references til basisklasser, kunne bruge objekter af afledte klasser uden yderligere instruktioner.<\/p>\n

Dette princip, som er en specifik definition af subtyper, blev foresl\u00e5et af Barbara Liskov i 1987 ved en konference i et hovedopl\u00e6g med titlen \u00abData Abstraction and Hierarchy\u00bb \u2014 deraf navnet.<\/p>\n

Interface Segregation Principle (ISP)<\/h3>\n

\nEndnu et SOLID-princip. If\u00f8lge dette skal et interface, der ikke anvendes, ikke implementeres. At f\u00f8lge dette princip hj\u00e6lper systemet med at forblive fleksibelt og egnet til refaktorisering, n\u00e5r logikken \u00e6ndres.<\/p>\n

Ofte opst\u00e5r denne situation, n\u00e5r et interface indeholder flere funktionaliteter, men kunden kun har brug for \u00e9n af dem.<\/p>\n

Da det er en kompleks opgave at skrive et interface, vil det v\u00e6re problematisk at \u00e6ndre det efter afslutningen af arbejdet uden at bryde noget.<\/p>\n

Fordelen ved ISP-princippet i Java er, at man f\u00f8rst skal implementere alle metoder, og f\u00f8rst derefter kan de bruges af klasserne. Derfor muligg\u00f8r princippet en reduktion af antallet af metoder.<\/p>\n

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

Programmering for interface, ikke implementering<\/h3>\n

\nHer er alt klart ud fra titlen. Anvendelsen af denne princip f\u00f8rer til skabelsen af fleksibel kode, der kan arbejde med enhver ny implementering af gr\u00e6nsefladen.<\/p>\n

Man b\u00f8r bruge typen af gr\u00e6nsefladen for variable, returnerede typer eller typen af metodeargumentet. Et eksempel er brugen af SuperClass frem for SubClass.<\/p>\n

Det vil sige:<\/p>\n

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

Og ikke:<\/p>\n

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

Her er en praktisk implementering af det, der n\u00e6vnes ovenfor.<\/p>\n

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

Delegationsprincippet<\/h3>\n

\nEt almindeligt eksempel er metoderne equals() og hashCode() i Java. N\u00e5r to objekter skal sammenlignes, bliver denne handling givet videre til den relevante klasse i stedet for klienten.<\/p>\n

Fordelen ved princippet er frav\u00e6ret af kode duplikering og relativt enkle \u00e6ndringer af adf\u00e6rden. Det kan ogs\u00e5 anvendes til delegation af begivenheder.<\/p>\n

\"10
\n
\nAlle disse principper g\u00f8r det muligt at skrive mere fleksibel, smuk og p\u00e5lidelig kode med h\u00f8j sammenkobling og lav sammenh\u00e6ng. Selvf\u00f8lgelig er teorien vigtig, men for at en udvikler virkelig kan anvende det l\u00e6rte, kr\u00e6ves der praksis. N\u00e6ste skridt efter at mestre OOP-principperne kan v\u00e6re at studere designm\u00f8nstre til l\u00f8sning af almindelige softwareudviklingsproblemer.<\/p>\n

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