Ganske ofte møter jeg utviklere som ikke har hørt om SOLID-prinsippene (vi . — Transl.) eller objektorientert programmering (OOP), eller har hørt om dem, men ikke bruker dem i praksis. Denne artikkelen beskriver fordelene med OOP-prinsipper som hjelper utvikleren i hans daglige arbeid. Noen av dem er velkjente, andre ikke så mye, så artikkelen vil være nyttig for både nybegynnere og erfarne programmerere.
Vi minner om: for alle Habr-lesere - en rabatt på 10 000 rubler når du melder deg på et hvilket som helst Skillbox-kurs ved å bruke Habr-kampanjekoden.
Skillbox anbefaler: Pedagogisk nettkurs .
TØRR (ikke gjenta deg selv)
Et ganske enkelt prinsipp, hvis essens er tydelig fra navnet: "Ikke gjenta deg selv." For en programmerer betyr dette behovet for å unngå duplikatkode, samt muligheten til å bruke abstraksjon i arbeidet sitt.
Hvis det er to repeterende seksjoner i koden, bør de kombineres til én metode. Hvis en hardkodet verdi brukes mer enn én gang, er det verdt å konvertere den til en offentlig konstant.
Dette er nødvendig for å forenkle koden og gjøre den enklere å vedlikeholde, som er hovedmålet med OOP. Du bør heller ikke overbruke fagforeningen, siden den samme koden ikke vil bestå verifisering med både OrderId og SSN.
Innkapslende endringer
De fleste selskapers programvareprodukter er i stadig utvikling. Dette betyr at endringer må gjøres i koden, den må støttes. Du kan gjøre livet ditt enklere ved å bruke innkapsling. Dette vil tillate deg å teste og vedlikeholde din eksisterende kodebase mer effektivt. .
Hvis du skriver i Java, da .
Åpent/lukket prinsipp
Dette prinsippet kan lett huskes ved å lese følgende utsagn: "Programvareenheter (klasser, moduler, funksjoner, etc.) bør være åpne for utvidelse, men lukket for modifikasjon." I praksis betyr dette at de kan la atferden endres uten å endre kildekoden.
Prinsippet er viktig når endringer i kildekoden krever revisjon av koden, enhetstesting og andre prosedyrer. Kode som følger åpent/lukket prinsippet endres ikke ved utvidelse, så det er langt færre problemer med det.
Her er et eksempel på kode som bryter med dette prinsippet.
Hvis du trenger å endre noe i det, vil det ta mye tid, siden alle deler av koden som har en forbindelse med ønsket fragment, må endres.
Åpenhet-lukkethet er forresten et av prinsippene til SOLID.
Single Responsibility Principle (SRP)
Et annet prinsipp fra SOLID-settet. Den sier at "det er bare én årsak som forårsaker en endring i klasse." Klassen løser bare ett problem. Det kan ha flere metoder, men hver av dem brukes bare for å løse et vanlig problem. Alle metoder og egenskaper skal kun tjene dette.
Verdien av dette prinsippet er at det løsner koblingen mellom den enkelte programvarekomponenten og koden. Hvis du legger til mer enn én funksjonalitet til en klasse, introduserer den et forhold mellom de to funksjonene. Dermed, hvis du endrer en av dem, er det stor sjanse for å ødelegge den andre, som er koblet til den første. Og dette betyr å øke testsyklusene for å identifisere alle problemer på forhånd.
Dependency Inversion Principle (DIP)
Ovenfor er et kodeeksempel der AppManager er avhengig av EventLogWriter, som igjen er tett koblet med AppManager. Hvis du trenger en annen måte å vise et varsel på, enten det er push, SMS eller e-post, må du endre AppManager-klassen.
Problemet kan løses ved hjelp av DIP. Så, i stedet for AppManager, ber vi om en EventLogWriter, som legges inn ved hjelp av rammeverket.
DIP gjør det mulig å enkelt erstatte individuelle moduler med andre ved å endre avhengighetsmodulen. Dette gjør det mulig å endre én modul uten å påvirke de andre.
Sammensetning i stedet for arv
Det er to hovedmåter å gjenbruke kode på: arv og sammensetning, som begge har sine egne fordeler og ulemper. Vanligvis foretrekkes den andre fordi den er mer fleksibel.
Komposisjon gir deg muligheten til å endre oppførselen til en klasse under kjøring ved å angi egenskapene. Ved implementering av grensesnitt brukes polymorfisme, noe som gir en mer fleksibel implementering.
Even Effective Java av Joshua Bloch anbefaler å velge komposisjon fremfor arv.
Barbara Liskov Substitusjonsprinsipp (LSP)
Et annet prinsipp fra SOLID-verktøysettet. Den sier at undertyper må være substituerbare for supertypen. Det vil si at metoder og funksjoner som fungerer med en superklasse skal kunne fungere uten problemer med underklassene.
LSP er knyttet til både enkeltansvarsprinsippet og delt ansvarsprinsippet. Hvis en klasse gir mer funksjonalitet enn en underklasse, vil ikke sistnevnte støtte noe av funksjonaliteten, noe som bryter med dette prinsippet.
Her er et stykke kode som motsier LSP.
Area(Rektangel r)-metoden beregner arealet til et rektangel. Programmet vil krasje etter å ha kjørt Square fordi Square ikke er et rektangel her. I henhold til LSP-prinsippet skal funksjoner som bruker referanser til basisklasser kunne bruke objekter av avledede klasser uten tilleggsinstruksjoner.
Dette prinsippet, som er en spesifikk definisjon av en undertype, ble foreslått av Barbara Liskov i et hovedinnlegg fra 1987 med tittelen "Dataabstraksjon og hierarki", derav navnet.
Interface Separation Principle (ISP)
Nok et SOLID prinsipp. Ifølge den skal et grensesnitt som ikke brukes, ikke implementeres. Å følge dette prinsippet hjelper systemet med å forbli fleksibelt og egnet for refaktorisering når det gjøres endringer i driftslogikken.
Oftest oppstår denne situasjonen når grensesnittet inneholder flere funksjoner samtidig, og klienten trenger bare en av dem.
Siden å skrive et grensesnitt er en vanskelig oppgave, vil det være en utfordring å endre det etter at arbeidet er fullført uten å bryte noe.
Fordelen med ISP-prinsippet i Java er at alle metoder må implementeres først, og først da kan de brukes av klasser. Derfor gjør prinsippet det mulig å redusere antall metoder.
Programmering for grensesnittet, ikke implementeringen
Alt her er klart av tittelen. Å bruke dette prinsippet fører til opprettelsen av fleksibel kode som kan fungere med enhver ny implementering av grensesnittet.
Du bør bruke grensesnitttypen for variabler, returtyper eller metodeargumenttypen. Et eksempel er å bruke SuperClass i stedet for SubClass.
Det er:
List numbers= getNumbers();
Men ikke:
ArrayList numbers = getNumbers();
Her er en praktisk gjennomføring av det som er diskutert ovenfor.
Delegeringsprinsipp
Et vanlig eksempel er metodene equals() og hashCode() i Java. Når det er nødvendig å sammenligne to objekter, delegeres denne handlingen til den tilsvarende klassen i stedet for klienten.
Fordelen med prinsippet er at det ikke er noen duplisering av kode og det er relativt enkelt å endre atferd. Det gjelder også arrangementsdelegering.
Alle disse prinsippene lar deg skrive mer fleksibel, vakker og pålitelig kode med høy kohesjon og lav kobling. Selvfølgelig er teori bra, men for at en utvikler faktisk skal bruke den tilegnete kunnskapen, trengs det praksis. Når du har mestret OOP-prinsippene, kan neste skritt være å lære designmønstre for å løse vanlige programvareutviklingsproblemer.
Skillbox anbefaler:
- Praktisk kurs .
- Anvendt nettkurs .
- Toårig praktisk kurs .
Kilde: www.habr.com