Jeg møder ofte udviklere, som ikke har hørt om SOLID-principperne (vi . — red.) eller om objektorienteret programmering (OOP), eller som har hørt om det, men ikke anvender det i praksis. I denne artikel beskrives fordelene ved OOP-principper, som hjælper udviklere i deres daglige arbejde. Nogle er velkendte, andre mindre så, så artiklen vil være nyttig for både begyndere og erfarne programmører.
Vi minder om: for alle læsere af «Habr» — rabat på 10.000 rubler ved tilmelding til ethvert Skillbox-kursus med rabatkoden «Habr».
Skillbox anbefaler: Online uddannelseskursus .
DRY (Don’t Repeat Yourself)
Et ret simpelt princip, hvis essens er klar fra navnet: «Gentag dig ikke». For programmører betyder det nødvendigheden af at undgå duplikeret kode samt muligheden for at anvende abstraktion i arbejdet.
Hvis der er to gentagne sektioner i koden, bør de kombineres til en metode. Hvis en fastværdi bruges mere end én gang, er det en god ide at omdanne den til en global konstant.
Dette er nødvendigt for at forenkle koden og gøre dens vedligeholdelse lettere, hvilket er det primære mål med OOP. Misbrug ikke sammenlægning, da den samme kode ikke vil bestå prøven som OrderId og SSN.
Indkapsling af ændringer
Softwareprodukter fra de fleste virksomheder udvikler sig konstant. Dette betyder, at koden skal ændres og vedligeholdes. Man kan forenkle livet ved hjælp af indkapsling. Dette muliggør mere effektiv testning og vedligeholdelse af den eksisterende kodebase. .
Hvis du skriver i Java, så .
Åbenhed/lukkethed-princippet
Dette princip kan nemt huskes ved at læse følgende udsagn: «Softwareenheder (klasser, moduler, funktioner osv.) skal være åbne for udvidelse, men lukkede for ændringer». I praksis betyder det, at de kan tillade ændring af adfærd uden at ændre den oprindelige kildekode.
Princippet er vigtigt, når ændringer i kildekoden kræver en gennemgang, modultestning og andre procedurer. Koden, der følger princippet om åbenhed/lukkethed, ændres ikke ved udvidelse, hvilket betyder, at der er langt færre problemer med den.
Her er et eksempel på kode, der overtræder dette princip.
Hvis der er behov for at ændre noget i den, vil det tage meget tid, fordi man skal ændre alle dele af koden, der har forbindelse til det relevante fragment.
Forresten er åbenhed-lukkethed et af SOLID-principperne.
Princippet om enkelt ansvar (SRP)
Endnu et princip fra SOLID-panelet. Det siger, at "der kun findes én årsag til at ændre en klasse". En klasse løser kun én opgave. Den kan have flere metoder, men hver af dem bruges kun til at løse den overordnede opgave. Alle metoder og egenskaber skal kun tjene dette formål.
Værdien af dette princip er, at det svækker forbindelsen mellem den enkelte softwarekomponent og koden. Hvis der tilføjes mere end én funktionalitet til en klasse, indfører det forbindelse mellem to funktioner. Således, hvis man ændrer en af dem, er der en stor risiko for at ødelægge den anden, der er relateret til den første. Dette betyder en øget testcyklus for at opdage alle problemer på forhånd.
Princippet om afhængighedsinversion (DIP)
Ovenstående er et eksempel på kode, hvor AppManager er afhængig af EventLogWriter, som igen er tæt knyttet til AppManager. Hvis man har brug for en anden måde at vise notifikationer på, hvad enten det er push, SMS eller e-mail, skal man ændre AppManager-klassen.
Problemet kan løses ved hjælp af DIP. Så i stedet for AppManager anmoder vi EventLogWriter, som vil blive indført ved hjælp af rammeværket.
DIP giver mulighed for uden problemer at udskifte individuelle moduler med andre ved at ændre afhængighedsmodulet. Dette giver mulighed for at ændre et modul uden at påvirke de andre.
Komposition frem for arv
Der er to primære metoder til genbrug af kode — arv og komposition, hvor hver har sine fordele og ulemper. Som regel gives der præference til den anden, da den er mere fleksibel.
Kompositionen giver mulighed for at ændre klassens adfærd under kørslen ved at indstille dens egenskaber. Når man implementerer grænseflader, anvendes polymorfi, hvilket giver en mere fleksibel implementering.
Selv “Effective Java” af Joshua Bloch anbefaler at foretrække komposition frem for arv.
Barbara Lisks substitutionsprincip (LSP)
Endnu et princip fra SOLID-værktøjskassen. 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.
LSP er relateret til både princippet om enkeltstående ansvar og princippet om ansvarssplit. Hvis en klasse giver mere funktionalitet end en underklasse, vil den sidstnævnte ikke understøtte nogle funktioner, hvilket bryder dette princip.
Her er et stykke kode, der strider imod LSP.
Metoden area(Rectangle r) beregner arealet af Rectangle. Programmet vil fejle efter udførelsen af Square, da Square her ikke er en Rectangle. Ifølge LSP skal funktioner, der bruger references til basisklasser, kunne bruge objekter af afledte klasser uden yderligere instruktioner.
Dette princip, som er en specifik definition af subtyper, blev foreslået af Barbara Liskov i 1987 ved en konference i et hovedoplæg med titlen «Data Abstraction and Hierarchy» — deraf navnet.
Interface Segregation Principle (ISP)
Endnu et SOLID-princip. Ifølge dette skal et interface, der ikke anvendes, ikke implementeres. At følge dette princip hjælper systemet med at forblive fleksibelt og egnet til refaktorisering, når logikken ændres.
Ofte opstår denne situation, når et interface indeholder flere funktionaliteter, men kunden kun har brug for én af dem.
Da det er en kompleks opgave at skrive et interface, vil det være problematisk at ændre det efter afslutningen af arbejdet uden at bryde noget.
Fordelen ved ISP-princippet i Java er, at man først skal implementere alle metoder, og først derefter kan de bruges af klasserne. Derfor muliggør princippet en reduktion af antallet af metoder.
Programmering for interface, ikke implementering
Her er alt klart ud fra titlen. Anvendelsen af denne princip fører til skabelsen af fleksibel kode, der kan arbejde med enhver ny implementering af grænsefladen.
Man bør bruge typen af grænsefladen for variable, returnerede typer eller typen af metodeargumentet. Et eksempel er brugen af SuperClass frem for SubClass.
Det vil sige:
List numbers = getNumbers();
Og ikke:
ArrayList numbers = getNumbers();
Her er en praktisk implementering af det, der nævnes ovenfor.
Delegationsprincippet
Et almindeligt eksempel er metoderne equals() og hashCode() i Java. Når to objekter skal sammenlignes, bliver denne handling givet videre til den relevante klasse i stedet for klienten.
Fordelen ved princippet er fraværet af kode duplikering og relativt enkle ændringer af adfærden. Det kan også anvendes til delegation af begivenheder.
Alle disse principper gør det muligt at skrive mere fleksibel, smuk og pålidelig kode med høj sammenkobling og lav sammenhæng. Selvfølgelig er teorien vigtig, men for at en udvikler virkelig kan anvende det lærte, kræves der praksis. Næste skridt efter at mestre OOP-principperne kan være at studere designmønstre til løsning af almindelige softwareudviklingsproblemer.
Skillbox anbefaler:
- Praktisk kursus .
- Anvendt online-kursus .
- Toårigt praktisk kursus .
Kilde: habr.com
