Inden for softwareudvikling, Objektorienteret design spiller en afgørende rolle, når det kommer til at skrive fleksibel, skalerbar, vedligeholdelig og genbrugelig kode. Der er så mange fordele ved at bruge OOD, men enhver udvikler bør også kende SOLID princippet for godt objektorienteret design i programmering. SOLID-princippet blev introduceret af Robert C. Martin, også kendt som Uncle Bob, og det er en kodningsstandard inden for programmering. Dette princip er et akronym af de fem principper, som er angivet nedenfor:

• Single Responsibility Principle (SRP)
• Åbent/lukket princip
• Liskovs substitutionsprincip (LSP)
• Interface Segregation Principle (ISP)
• Afhængighedsinversionsprincip (DIP)

SOLID-princippet hjælper med at reducere tæt kobling. Tæt kobling betyder, at en gruppe klasser er meget afhængige af hinanden, hvilket du bør undgå i din kode.

• Det modsatte af tæt kobling er løs kobling, og din kode betragtes som en god kode, når den har løst koblede klasser.
• Løst koblede klasser minimerer ændringer i din kode, hjælper med at gøre koden mere genbrugelig, vedligeholdelsesvenlig, fleksibel og stabil. Lad os nu diskutere disse principper en efter en...

1. Princip for enkelt ansvar

Dette princip siger det En klasse bør kun have én grund til at skifte hvilket betyder, at hver klasse skal have et enkelt ansvar eller enkelt job eller enkelt formål. Med andre ord bør en klasse kun have ét job eller formål i softwaresystemet.

jvm i java

Lad os forstå princippet om enkelt ansvar ved at bruge et eksempel:

Forestil dig en bager, der er ansvarlig for at bage brød. Bagerens rolle er at fokusere på opgaven med at bage brød og sikre, at brødet er af høj kvalitet, ordentligt bagt og lever op til bageriets standarder.

• Men hvis bageren også er ansvarlig for at administrere varebeholdningen, bestille forsyninger, betjene kunder og rense bageriet, ville dette være i strid med SRP.
• Hver af disse opgaver repræsenterer et separat ansvar, og ved at kombinere dem kan bagerens fokus og effektivitet i at bage brød blive kompromitteret.
• For at overholde SRP kunne bageriet tildele forskellige roller til forskellige individer eller teams. For eksempel kan der være en særskilt person eller et team, der er ansvarlig for at administrere varelageret, en anden for at bestille forsyninger, en anden for at betjene kunder og en anden for rengøring af bageriet.

2. Åbent/lukket princip

Dette princip siger det Softwareenheder (klasser, moduler, funktioner osv.) bør være åbne for udvidelse, men lukkede for ændring hvilket betyder, at du bør være i stand til at udvide en klasseadfærd uden at ændre den.

markdown billede

Lad os forstå åbent/lukket princip ved hjælp af et eksempel:

Forestil dig, at du har en klasse, der hedderPaymentProcessor>der behandler betalinger for en netbutik. I første omgangPaymentProcessor>klasse understøtter kun behandling af betalinger med kreditkort. Du ønsker dog at udvide dens funktionalitet til også at understøtte behandling af betalinger ved hjælp af PayPal.

I stedet for at ændre det eksisterendePaymentProcessor>klasse for at tilføje PayPal-support, kan du oprette en ny klasse kaldetPayPalPaymentProcessor>der udviderPaymentProcessor>klasse. På denne mådePaymentProcessor>klasse forbliver lukket for ændring, men åben for forlængelse, i overensstemmelse med Open-Closed-princippet

3. Liskovs Substitutionsprincip

Princippet blev indført af Barbara Liskov i 1987 og efter dette princip Afledte klasser eller børneklasser skal kunne erstatte deres basis- eller forældreklasser . Dette princip sikrer, at enhver klasse, der er barn af en forældreklasse, skal kunne bruges i stedet for sin forælder uden nogen uventet adfærd.

Lad os forstå Liskovs substitutionsprincip ved at bruge et eksempel:

Et af de klassiske eksempler på dette princip er et rektangel med fire sider. Et rektangels højde kan være en hvilken som helst værdi, og bredde kan være en hvilken som helst værdi. Et kvadrat er et rektangel med samme bredde og højde. Så vi kan sige, at vi kan udvide rektangelklassens egenskaber til kvadratisk klasse.

For at gøre det skal du bytte den underordnede (firkantede) klasse med en overordnet (rektangel) klasse, så den passer til definitionen af ​​et kvadrat med fire lige store sider, men en afledt klasse påvirker ikke forældreklassens adfærd, så hvis du vil gøre det at det vil overtræde Liskov Substitutionsprincippet.

4. Interface Segregation Princip

Dette princip er det første princip, der gælder for Interfaces i stedet for klasser i SOLID, og ​​det ligner princippet om enkelt ansvar. Det står der Tving ikke nogen klient til at implementere en grænseflade, som er irrelevant for dem . Her er dit hovedmål at fokusere på at undgå fedt interface og give fortrinsret til mange små klientspecifikke interfaces. Du bør foretrække mange klientgrænseflader frem for én generel grænseflade, og hver grænseflade bør have et specifikt ansvar.

parse streng til int

Lad os forstå grænsefladesegregationsprincippet ved hjælp af et eksempel:

Antag, hvis du går ind på en restaurant, og du er ren vegetar. Tjeneren i den restaurant gav dig menukortet, som inkluderer vegetariske genstande, ikke-vegetariske genstande, drikkevarer og slik.

• I dette tilfælde bør du som kunde have et menukort, der kun indeholder vegetariske varer, ikke alt, hvad du ikke spiser i din mad. Her bør menuen være forskellig for forskellige typer kunder.
• Det fælles eller generelle menukort for alle kan opdeles i flere kort i stedet for kun ét. Brug af dette princip hjælper med at reducere bivirkningerne og hyppigheden af ​​nødvendige ændringer.

5. Afhængighedsinversionsprincip

The Dependency Inversion Principle (DIP) er et princip i objektorienteret design, der siger det Moduler på højt niveau bør ikke afhænge af moduler på lavt niveau. Begge burde afhænge af abstraktioner . Derudover bør abstraktioner ikke afhænge af detaljer. Detaljer bør afhænge af abstraktioner.

• I enklere vendinger foreslår DIP, at klasser bør stole på abstraktioner (f.eks. grænseflader eller abstrakte klasser) snarere end konkrete implementeringer.
• Dette giver mulighed for mere fleksibel og afkoblet kode, hvilket gør det nemmere at ændre implementeringer uden at påvirke andre dele af kodebasen.

Lad os forstå afhængighedsinversionsprincippet ved hjælp af et eksempel:

I et softwareudviklingsteam er udviklere afhængige af et abstrakt versionskontrolsystem (f.eks. Git) til at styre og spore ændringer i kodebasen. De er ikke afhængige af specifikke detaljer om, hvordan Git fungerer internt.

erstatte streng i java

Dette giver udviklere mulighed for at fokusere på at skrive kode uden at skulle forstå forviklingerne ved implementering af versionskontrol.