Inom mjukvaruutveckling, Objektorienterad design spelar en avgörande roll när det gäller att skriva flexibel, skalbar, underhållbar och återanvändbar kod. Det finns så många fördelar med att använda OOD men varje utvecklare bör också känna till SOLID-principen för bra objektorienterad design i programmering. SOLID-principen introducerades av Robert C. Martin, även känd som Uncle Bob och det är en kodningsstandard inom programmering. Denna princip är en akronym av de fem principerna som anges nedan:

• Single Responsibility Principle (SRP)
• Öppen/stängd princip
• Liskovs substitutionsprincip (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

SOLID-principen hjälper till att minska tät koppling. Tät koppling betyder att en grupp klasser är starkt beroende av varandra vilket du bör undvika i din kod.

• Motsatsen till tät koppling är lös koppling och din kod anses vara en bra kod när den har löst kopplade klasser.
• Löst kopplade klasser minimerar ändringar i din kod, hjälper till att göra koden mer återanvändbar, underhållbar, flexibel och stabil. Låt oss nu diskutera dessa principer en efter en...

1. Principen om ett enda ansvar

Denna princip säger det En klass ska bara ha en anledning att byta vilket innebär att varje klass ska ha ett enda ansvar eller ett enda jobb eller ett enda syfte. Med andra ord bör en klass bara ha ett jobb eller syfte inom mjukvarusystemet.

Viktig

Låt oss förstå principen om ett enda ansvar med ett exempel:

Föreställ dig en bagare som ansvarar för att baka bröd. Bagarens roll är att fokusera på uppgiften att baka bröd, se till att brödet är av hög kvalitet, rätt bakat och uppfyller bageriets krav.

• Men om bagaren också är ansvarig för att hantera inventeringen, beställa förnödenheter, betjäna kunder och städa bageriet, skulle detta bryta mot SRP.
• Var och en av dessa uppgifter representerar ett separat ansvar, och genom att kombinera dem kan bagarens fokus och effektivitet i att baka bröd äventyras.
• För att följa SRP kan bageriet tilldela olika roller till olika individer eller team. Det kan till exempel vara en separat person eller team som ansvarar för att hantera inventeringen, en annan för att beställa förnödenheter, en annan för att betjäna kunder och en annan för att städa bageriet.

2. Öppen/stängd princip

Denna princip säger det Programvaruenheter (klasser, moduler, funktioner etc.) bör vara öppna för förlängning, men stängda för modifiering vilket innebär att du bör kunna utöka ett klassbeteende utan att ändra det.

Låt oss förstå den öppna/stängda principen med ett exempel:

Föreställ dig att du har en klass som heterPaymentProcessor>som behandlar betalningar för en webbutik. Till en börjanPaymentProcessor>klass stöder endast behandling av betalningar med kreditkort. Du vill dock utöka dess funktionalitet till att även stödja bearbetning av betalningar med PayPal.

snabbsorteringsalgoritm

Istället för att modifiera det befintligaPaymentProcessor>klass för att lägga till PayPal-stöd, kan du skapa en ny klass som heterPayPalPaymentProcessor>som förlängerPaymentProcessor>klass. På det här sättetPaymentProcessor>klass förblir stängd för modifiering men öppen för förlängning, i enlighet med Open-Closed-principen

3. Liskovs ersättningsprincip

Principen infördes av Barbara Liskov 1987 och enligt denna princip Härledda klasser eller underordnade klasser måste kunna ersätta deras bas- eller föräldraklasser . Denna princip säkerställer att varje klass som är barn till en förälderklass ska kunna användas i stället för sin förälder utan något oväntat beteende.

Låt oss förstå Liskovs substitutionsprincip med ett exempel:

Ett av de klassiska exemplen på denna princip är en rektangel med fyra sidor. En rektangels höjd kan vara vilket värde som helst och bredd kan vara vilket värde som helst. En kvadrat är en rektangel med lika bredd och höjd. Så vi kan säga att vi kan utöka rektangelklassens egenskaper till kvadratisk klass.

För att göra det måste du byta ut den underordnade (fyrkantiga) klassen med den överordnade (rektangeln) klassen för att passa definitionen av en kvadrat med fyra lika sidor men en härledd klass påverkar inte moderklassens beteende, så om du vill göra det att det kommer att bryta mot Liskov Substitutionsprincipen.

javascript-variabel global

4. Gränssnittssegregationsprincip

Denna princip är den första principen som gäller för gränssnitt istället för klasser i SOLID och den liknar principen om ett ansvar. Det står det tvinga inte någon klient att implementera ett gränssnitt som är irrelevant för dem . Här är ditt huvudmål att fokusera på att undvika fettgränssnitt och ge företräde åt många små klientspecifika gränssnitt. Du bör föredra många klientgränssnitt snarare än ett allmänt gränssnitt och varje gränssnitt bör ha ett specifikt ansvar.

Låt oss förstå gränssnittssegregationsprincipen med ett exempel:

Tänk om du går in på en restaurang och du är ren vegetarian. Servitören i den restaurangen gav dig menykortet som innehåller vegetariska föremål, icke-vegetariska föremål, drycker och godis.

• I det här fallet bör du som kund ha ett menykort som endast innehåller vegetariska varor, inte allt som du inte äter i maten. Här ska menyn vara olika för olika typer av kunder.
• Det gemensamma eller allmänna menykortet för alla kan delas upp i flera kort istället för bara ett. Att använda denna princip hjälper till att minska biverkningarna och frekvensen av nödvändiga förändringar.

5. Beroendeinversionsprincip

Dependency Inversion Principle (DIP) är en princip inom objektorienterad design som säger det Högnivåmoduler bör inte vara beroende av lågnivåmoduler. Båda bör bero på abstraktioner . Dessutom bör abstraktioner inte bero på detaljer. Detaljer bör bero på abstraktioner.

• I enklare termer föreslår DIP att klasser bör förlita sig på abstraktioner (t.ex. gränssnitt eller abstrakta klasser) snarare än konkreta implementeringar.
• Detta möjliggör mer flexibel och frikopplad kod, vilket gör det lättare att ändra implementeringar utan att påverka andra delar av kodbasen.

Låt oss förstå beroendeinversionsprincipen med ett exempel:

trädkarta

I ett mjukvaruutvecklingsteam är utvecklare beroende av ett abstrakt versionskontrollsystem (t.ex. Git) för att hantera och spåra ändringar i kodbasen. De är inte beroende av specifika detaljer om hur Git fungerar internt.

Detta gör att utvecklare kan fokusera på att skriva kod utan att behöva förstå krångligheterna med implementering av versionskontroll.