Bij softwareontwikkeling is Objectgericht ontwerp speelt een cruciale rol als het gaat om het schrijven van flexibele, schaalbare, onderhoudbare en herbruikbare code. Er zijn zoveel voordelen aan het gebruik van OOD, maar elke ontwikkelaar zou ook het SOLID-principe moeten kennen voor goed objectgeoriënteerd ontwerp bij het programmeren. Het SOLID-principe werd geïntroduceerd door Robert C. Martin, ook wel bekend als Uncle Bob, en is een coderingsstandaard bij het programmeren. Dit principe is een acroniem van de vijf principes die hieronder worden gegeven:

• Principe van enkele verantwoordelijkheid (SRP)
• Open/gesloten principe
• Liskovs substitutieprincipe (LSP)
• Interface-segregatieprincipe (ISP)
• Afhankelijkheidsinversieprincipe (DIP)

Het SOLID-principe helpt bij het verminderen van strakke koppeling. Strakke koppeling betekent dat een groep klassen sterk van elkaar afhankelijk is, wat u in uw code moet vermijden.

• Het tegenovergestelde van strakke koppeling is losse koppeling en uw code wordt als een goede code beschouwd als deze losjes gekoppelde klassen heeft.
• Losjes gekoppelde klassen minimaliseren veranderingen in uw code en helpen de code herbruikbaarder, onderhoudbaarder, flexibeler en stabieler te maken. Laten we nu deze principes één voor één bespreken…

1. Principe van gezamenlijke verantwoordelijkheid

Dit principe stelt dat Een klasse mag maar één reden hebben om te veranderen wat betekent dat elke klas één enkele verantwoordelijkheid, één taak of één doel moet hebben. Met andere woorden: een klas mag slechts één taak of doel binnen het softwaresysteem hebben.

Lijst sorteer Java

Laten we het Single Responsibility-principe begrijpen aan de hand van een voorbeeld:

Stel je een bakker voor die verantwoordelijk is voor het bakken van brood. De rol van de bakker is om zich te concentreren op het bakken van brood en ervoor te zorgen dat het brood van hoge kwaliteit is, op de juiste manier gebakken is en voldoet aan de normen van de bakkerij.

• Als de bakker echter ook verantwoordelijk is voor het beheer van de voorraad, het bestellen van benodigdheden, het bedienen van klanten en het schoonmaken van de bakkerij, zou dit in strijd zijn met de SRP.
• Elk van deze taken vertegenwoordigt een afzonderlijke verantwoordelijkheid, en door ze te combineren kunnen de focus en effectiviteit van de bakker bij het bakken van brood in gevaar komen.
• Om aan de SRP te voldoen, zou de bakkerij verschillende rollen aan verschillende individuen of teams kunnen toewijzen. Er kan bijvoorbeeld een afzonderlijke persoon of team zijn dat verantwoordelijk is voor het beheer van de inventaris, een ander voor het bestellen van benodigdheden, een ander voor het bedienen van klanten en een ander voor het schoonmaken van de bakkerij.

2. Open/gesloten principe

Dit principe stelt dat Software-entiteiten (klassen, modules, functies, etc.) moeten open zijn voor uitbreiding, maar gesloten voor wijziging wat betekent dat je een klassengedrag zou moeten kunnen uitbreiden, zonder het te wijzigen.

Laten we het open/gesloten principe begrijpen aan de hand van een voorbeeld:

Stel je voor dat er een klas wordt gebeldPaymentProcessor>die betalingen voor een online winkel verwerkt. Aanvankelijk was dePaymentProcessor>class ondersteunt alleen het verwerken van betalingen met creditcards. U wilt de functionaliteit echter uitbreiden om ook de verwerking van betalingen via PayPal te ondersteunen.

q4 maanden

In plaats van het bestaande aan te passenPaymentProcessor>klasse om PayPal-ondersteuning toe te voegen, kunt u een nieuwe klasse maken met de naamPayPalPaymentProcessor>dat verlengt dePaymentProcessor>klas. Op deze manier kan dePaymentProcessor>De klasse blijft gesloten voor wijziging, maar open voor uitbreiding, waarbij het Open-Gesloten Principe wordt nageleefd

3. Liskovs vervangingsprincipe

Het principe werd in 1987 door Barbara Liskov geïntroduceerd en volgens dit principe Afgeleide of onderliggende klassen moeten vervangbaar zijn door hun basis- of bovenliggende klassen . Dit principe zorgt ervoor dat elke klasse die het kind is van een ouderklasse, zonder onverwacht gedrag bruikbaar moet zijn in de plaats van de ouder.

Laten we het substitutieprincipe van Liskov begrijpen aan de hand van een voorbeeld:

Een van de klassieke voorbeelden van dit principe is een rechthoek met vier zijden. De hoogte van een rechthoek kan elke waarde zijn en de breedte kan elke waarde zijn. Een vierkant is een rechthoek met gelijke breedte en hoogte. We kunnen dus zeggen dat we de eigenschappen van de rechthoekklasse kunnen uitbreiden naar de vierkante klasse.

Om dat te doen moet je de child-klasse (vierkant) omwisselen met de parent-klasse (rechthoek) om te voldoen aan de definitie van een vierkant met vier gelijke zijden, maar een afgeleide klasse heeft geen invloed op het gedrag van de parent-klasse, dus als je dat doet dat het het Liskov-substitutiebeginsel zal schenden.

Java-selectie sorteren

4. Principe van interfacesegregatie

Dit principe is het eerste principe dat van toepassing is op interfaces in plaats van op klassen in SOLID en is vergelijkbaar met het principe van enkele verantwoordelijkheid. Het zegt dat dwing geen enkele klant om een ​​interface te implementeren die voor hem of haar niet relevant is . Hier is uw belangrijkste doel om u te concentreren op het vermijden van een dikke interface en de voorkeur te geven aan veel kleine klantspecifieke interfaces. U zou de voorkeur moeten geven aan veel clientinterfaces in plaats van één algemene interface, en elke interface zou een specifieke verantwoordelijkheid moeten hebben.

Laten we het interfacesegregatieprincipe begrijpen aan de hand van een voorbeeld:

Stel dat je een restaurant binnenstapt en je bent puur vegetarisch. De ober in dat restaurant gaf je de menukaart met vegetarische producten, niet-vegetarische producten, drankjes en snoep.

• In dit geval moet u als klant een menukaart hebben waarop alleen vegetarische producten staan, en niet alles wat u niet in uw eten eet. Hier moet het menu verschillend zijn voor verschillende soorten klanten.
• De gemeenschappelijke of algemene menukaart voor iedereen kan worden opgedeeld in meerdere kaarten in plaats van slechts één. Het gebruik van dit principe helpt bij het verminderen van de bijwerkingen en de frequentie van vereiste veranderingen.

5. Principe van afhankelijkheidsinversie

Het Dependency Inversion Principle (DIP) is een principe in objectgeoriënteerd ontwerpen dat dit stelt Modules op hoog niveau mogen niet afhankelijk zijn van modules op laag niveau. Beide moeten afhankelijk zijn van abstracties . Bovendien mogen abstracties niet afhankelijk zijn van details. Details moeten afhangen van abstracties.

• In eenvoudiger bewoordingen suggereert de DIP dat klassen moeten vertrouwen op abstracties (bijvoorbeeld interfaces of abstracte klassen) in plaats van op concrete implementaties.
• Dit zorgt voor flexibelere en ontkoppelde code, waardoor het gemakkelijker wordt om implementaties te wijzigen zonder andere delen van de codebasis te beïnvloeden.

Laten we het afhankelijkheidsinversieprincipe begrijpen aan de hand van een voorbeeld:

bash elif

In een softwareontwikkelingsteam zijn ontwikkelaars afhankelijk van een abstract versiebeheersysteem (bijvoorbeeld Git) om wijzigingen in de codebase te beheren en bij te houden. Ze zijn niet afhankelijk van specifieke details over hoe Git intern werkt.

Hierdoor kunnen ontwikkelaars zich concentreren op het schrijven van code zonder de complexiteit van de implementatie van versiebeheer te hoeven begrijpen.