I programvareutvikling, Objektorientert design spiller en avgjørende rolle når det gjelder å skrive fleksibel, skalerbar, vedlikeholdbar og gjenbrukbar kode. Det er så mange fordeler med å bruke OOD, men enhver utvikler bør også kjenne til SOLID-prinsippet for god objektorientert design i programmering. SOLID-prinsippet ble introdusert av Robert C. Martin, også kjent som onkel Bob, og det er en kodestandard innen programmering. Dette prinsippet er et akronym av de fem prinsippene som er gitt nedenfor:

• Single Responsibility Principle (SRP)
• Åpent/lukket prinsipp
• Liskovs erstatningsprinsipp (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

SOLID-prinsippet hjelper til med å redusere tett kobling. Tett kobling betyr at en gruppe klasser er svært avhengige av hverandre, noe du bør unngå i koden din.

• Det motsatte av tett kobling er løs kobling og koden din anses som en god kode når den har løst koblede klasser.
• Løst koblede klasser minimerer endringer i koden din, bidrar til å gjøre koden mer gjenbrukbar, vedlikeholdbar, fleksibel og stabil. La oss nå diskutere disse prinsippene én etter én …

1. Prinsippet om enkelt ansvar

Dette prinsippet sier det En klasse skal bare ha én grunn til å endre seg som betyr at hver klasse bør ha et enkelt ansvar eller en enkelt jobb eller enkelt formål. Med andre ord skal en klasse bare ha én jobb eller hensikt i programvaresystemet.

jvm i java

La oss forstå enkeltansvarsprinsippet ved å bruke et eksempel:

Se for deg en baker som har ansvaret for å bake brød. Bakerens rolle er å fokusere på oppgaven med å bake brød, sørge for at brødet er av høy kvalitet, riktig bakt og oppfyller bakeriets standarder.

• Men hvis bakeren også er ansvarlig for å administrere varelageret, bestille forsyninger, betjene kunder og rengjøre bakeriet, vil dette være i strid med SRP.
• Hver av disse oppgavene representerer et eget ansvar, og ved å kombinere dem kan bakerens fokus og effektivitet i å bake brød bli kompromittert.
• For å overholde SRP, kan bakeriet tildele forskjellige roller til forskjellige individer eller lag. For eksempel kan det være en egen person eller team som er ansvarlig for å administrere varelageret, en annen for å bestille forsyninger, en annen for å betjene kunder og en annen for å rengjøre bakeriet.

2. Åpent/lukket prinsipp

Dette prinsippet sier det Programvareenheter (klasser, moduler, funksjoner osv.) bør være åpne for utvidelse, men stengt for modifikasjoner som betyr at du skal kunne utvide en klasseatferd uten å endre den.

markdown-bilde

La oss forstå åpent/lukket prinsipp ved å bruke et eksempel:

Tenk deg at du har en klasse som heterPaymentProcessor>som behandler betalinger for en nettbutikk. I utgangspunktetPaymentProcessor>klasse støtter kun behandling av betalinger med kredittkort. Du vil imidlertid utvide funksjonaliteten til også å støtte behandling av betalinger med PayPal.

I stedet for å modifisere det eksisterendePaymentProcessor>klasse for å legge til PayPal-støtte, kan du opprette en ny klasse kaltPayPalPaymentProcessor>som forlengerPaymentProcessor>klasse. På denne måtenPaymentProcessor>klasse forblir stengt for modifikasjon, men åpen for utvidelse, i henhold til Open-Closed-prinsippet

3. Liskovs substitusjonsprinsipp

Prinsippet ble introdusert av Barbara Liskov i 1987 og etter dette prinsippet Avledede eller underordnede klasser må være substituerbare med basis- eller overordnede klasser . Dette prinsippet sikrer at enhver klasse som er barn til en overordnet klasse, skal kunne brukes i stedet for sin forelder uten uventet oppførsel.

La oss forstå Liskovs substitusjonsprinsipp ved å bruke et eksempel:

Et av de klassiske eksemplene på dette prinsippet er et rektangel med fire sider. Et rektangels høyde kan være en hvilken som helst verdi og bredde kan være en hvilken som helst verdi. Et kvadrat er et rektangel med lik bredde og høyde. Så vi kan si at vi kan utvide egenskapene til rektangelklassen til kvadratisk klasse.

For å gjøre det må du bytte underordnet (kvadratisk) klasse med overordnet (rektangel) klasse for å passe til definisjonen av et kvadrat med fire like sider, men en avledet klasse påvirker ikke oppførselen til overordnet klasse, så hvis du vil gjøre det at det vil bryte med Liskov Substitusjonsprinsippet.

4. Grensesnittsegregeringsprinsipp

Dette prinsippet er det første prinsippet som gjelder for grensesnitt i stedet for klasser i SOLID, og ​​det ligner enkeltansvarsprinsippet. Det står det ikke tving noen klient til å implementere et grensesnitt som er irrelevant for dem . Her er hovedmålet ditt å fokusere på å unngå fettgrensesnitt og gi preferanse til mange små klientspesifikke grensesnitt. Du bør foretrekke mange klientgrensesnitt fremfor ett generelt grensesnitt, og hvert grensesnitt bør ha et spesifikt ansvar.

velg som

La oss forstå grensesnittsegregeringsprinsippet ved å bruke et eksempel:

Tenk deg at hvis du går inn på en restaurant og du er ren vegetarianer. Servitøren i den restauranten ga deg menykortet som inkluderer vegetariske varer, ikke-vegetariske varer, drinker og søtsaker.

• I dette tilfellet bør du som kunde ha et menykort som kun inneholder vegetariske varer, ikke alt du ikke spiser i maten. Her skal menyen være forskjellig for ulike typer kunder.
• Det felles eller generelle menykortet for alle kan deles inn i flere kort i stedet for bare ett. Bruk av dette prinsippet bidrar til å redusere bivirkningene og frekvensen av nødvendige endringer.

5. Avhengighetsinversjonsprinsipp

The Dependency Inversion Principle (DIP) er et prinsipp i objektorientert design som sier det Høynivåmoduler bør ikke være avhengig av lavnivåmoduler. Begge bør avhenge av abstraksjoner . I tillegg bør abstraksjoner ikke avhenge av detaljer. Detaljer bør avhenge av abstraksjoner.

• I enklere termer foreslår DIP at klasser bør stole på abstraksjoner (f.eks. grensesnitt eller abstrakte klasser) i stedet for konkrete implementeringer.
• Dette gir mulighet for mer fleksibel og frakoblet kode, noe som gjør det enklere å endre implementeringer uten å påvirke andre deler av kodebasen.

La oss forstå avhengighetsinversjonsprinsippet ved å bruke et eksempel:

I et programvareutviklingsteam er utviklere avhengige av et abstrakt versjonskontrollsystem (f.eks. Git) for å administrere og spore endringer i kodebasen. De er ikke avhengige av spesifikke detaljer om hvordan Git fungerer internt.

erstatte streng i java

Dette lar utviklere fokusere på å skrive kode uten å måtte forstå vanskelighetene med implementering av versjonskontroll.