Ganske ofte møder jeg udviklere, der ikke har hørt om principperne for SOLID (vi . - Oversættelse) eller objektorienteret programmering (OOP), eller hørt, men brug dem ikke i praksis. Denne artikel beskriver fordelene ved OOP-principper, der hjælper udvikleren i hans daglige arbejde. Nogle af dem er velkendte, andre ikke så meget, så artiklen vil være nyttig for både begyndere og allerede erfarne programmører.
Påmindelse: for alle læsere af "Habr" - en rabat på 10 rubler ved tilmelding til ethvert Skillbox-kursus ved hjælp af "Habr"-kampagnekoden.
Skillbox anbefaler: Pædagogisk online kursus .
TØR (Gentag ikke dig selv)
Et ret simpelt princip, hvis essens fremgår af navnet: "Gentag ikke dig selv." For en programmør betyder dette behovet for at undgå duplikeret kode, samt evnen til at bruge abstraktion i arbejdet.
Hvis der er to gentagne afsnit i koden, skal de kombineres til én metode. Hvis en hårdkodet værdi bruges mere end én gang, er det værd at konvertere den til en offentlig konstant.
Dette er nødvendigt for at forenkle koden og gøre den nemmere at vedligeholde, hvilket er OOP's hovedopgave. Du bør heller ikke misbruge fagforeningen, da den samme kode ikke vil bestå kontrollen med både OrderId og SSN.
Skift indkapsling
De fleste virksomheders softwareprodukter er i konstant udvikling. Det betyder, at koden skal ændres, den skal vedligeholdes. Du kan gøre dit liv lettere med indkapsling. Dette vil give dig mulighed for mere effektivt at teste og vedligeholde din eksisterende kodebase. .
Hvis du skriver i Java så .
Princippet om åbenhed/nærhed
Dette princip kan let huskes ved at læse følgende erklæring: "Softwareenheder (klasser, moduler, funktioner osv.) bør være åbne for udvidelse, men lukkede for modifikation." I praksis betyder det, at de kan tillade, at deres adfærd ændres uden at ændre kildekoden.
Princippet er vigtigt, når ændringer i kildekoden kræver revisioner, enhedstest og andre procedurer. Kode, der adlyder åben/lukket princippet, ændres ikke ved udvidelse, så der er meget færre problemer med det.
Her er et eksempel på kode, der overtræder dette princip.
Hvis du skal ændre noget i det, vil det tage meget tid, fordi du skal ændre alle de dele af koden, der har en forbindelse med det ønskede fragment.
Åbenhed-lukkethed er i øvrigt et af principperne i SOLID.
Single Responsibility Principle (SRP)
Endnu et princip fra SOLID-sættet. Den siger, at "der er kun én grund, der fører til et klasseskifte." Klassen har kun én opgave. Det kan have flere metoder, men hver af dem bruges kun til at løse et fælles problem. Alle metoder og egenskaber bør kun tjene dette.
Værdien af dette princip er, at det løsner forbindelsen mellem et enkelt stykke software og koden. Tilføjelse af mere end én funktionalitet til en klasse introducerer et forhold mellem de to funktioner. Således, hvis du ændrer en af dem, er der en stor chance for at forkæle den anden, relateret til den første. Og det betyder at øge testcyklusserne for at identificere alle problemer på forhånd.
Afhængighedsinversionsprincip (DIP)
Ovenstående er et kodeeksempel, hvor AppManager afhænger af EventLogWriter, som igen er tæt knyttet til AppManager. Hvis du har brug for en anden måde at vise notifikationen på, det være sig et push, SMS eller e-mail, skal du ændre AppManager-klassen.
Problemet kan løses med DIP. Så i stedet for AppManager anmoder vi om en EventLogWriter, som vil blive injiceret ved hjælp af rammen.
DIP gør det muligt nemt at udskifte enkelte moduler med andre ved at ændre afhængighedsmodulet. Dette gør det muligt at ændre et modul uden at påvirke de andre.
Sammensætning i stedet for arv
De to vigtigste måder at genbruge kode på er arv og sammensætning, hver med sine egne fordele og ulemper. Den anden foretrækkes normalt, fordi den er mere fleksibel.
Sammensætning giver dig mulighed for at ændre adfærden for en klasse under kørsel ved at indstille dens egenskaber. Ved implementering af grænseflader anvendes polymorfi, hvilket giver en mere fleksibel implementering.
Selv "Effektiv Java" anbefaler Joshua Bloch at foretrække komposition frem for arv.
Barbara Liskov udskiftningsprincip (LSP)
Et andet princip fra SOLID-værktøjssættet. Den siger, at undertyper skal være udskiftelige for en supertype. Det vil sige, at metoder og funktioner, der fungerer med en superklasse, skal kunne fungere uden problemer med dens underklasser.
LSP er relateret til både princippet om enkelt ansvar og princippet om adskillelse af ansvar. Hvis en klasse giver mere funktionalitet end en underklasse, vil sidstnævnte ikke understøtte en eller anden funktionalitet, hvilket overtræder dette princip.
Her er et stykke kode, der modsiger LSP.
Area(Rektangel r) metoden beregner arealet af et rektangel. Programmet vil gå ned efter at have udført Square, da Square ikke er et rektangel her. Ifølge LSP-princippet skal funktioner, der bruger referencer til basisklasser, kunne bruge objekter af afledte klasser uden yderligere instruktioner.
Dette princip, som er en specifik definition af en undertype, blev foreslået af Barbara Liskov i en konference-keynote fra 1987 kaldet "Data Abstraktion og Hierarki" - deraf navnet.
Interface Separation Principle (ISP)
Endnu et SOLID princip. Ifølge ham bør en grænseflade, der ikke bruges, ikke implementeres. At følge dette princip hjælper systemet med at forblive fleksibelt og refaktorabelt, når der foretages ændringer i arbejdslogikken.
Oftest opstår denne situation, når grænsefladen indeholder flere funktioner på én gang, og klienten kun har brug for én af dem.
Da det er en kompleks opgave at skrive en grænseflade, vil det, efter at arbejdet er afsluttet, være et problem at ændre det uden at bryde noget.
Fordelen ved ISP-princippet i Java er, at alle metoder skal implementeres først, og først derefter kan de bruges af klasser. Derfor gør princippet det muligt at reducere antallet af metoder.
Programmering til en grænseflade, ikke en implementering
Her fremgår alt af navnet. Anvendelse af dette princip fører til fleksibel kode, der kan fungere med enhver ny grænsefladeimplementering.
Du bør bruge en grænsefladetype til variabler, returtyper eller typen af et metodeargument. Et eksempel er at bruge SuperClass i stedet for SubClass.
Det er:
List numbers= getNumbers();
Men ikke:
ArrayList numbers = getNumbers();
Her er en praktisk implementering af det, der er sagt ovenfor.
Delegationsprincippet
Et almindeligt eksempel er equals() og hashCode() metoderne i Java. Når to objekter skal sammenlignes, delegeres denne handling til den relevante klasse i stedet for klientklassen.
Fordelen ved princippet er, at der ikke er nogen duplikering af kode, og det er relativt nemt at ændre adfærd. Det gælder også for begivenhedsdelegering.
Alle disse principper giver dig mulighed for at skrive mere fleksibel, smuk og pålidelig kode med høj sammenhæng og lav kobling. Selvfølgelig er teori godt, men for at en udvikler virkelig kan begynde at bruge den opnåede viden, er der brug for øvelse. Det næste trin efter at have mestret principperne for OOP kan være studiet af designmønstre til løsning af almindelige softwareudviklingsproblemer.
Skillbox anbefaler:
- Praktisk kursus .
- Anvendt online kursus .
- To-årigt praktisk kursus .
Kilde: www.habr.com