Ik kom vrij vaak ontwikkelaars tegen die niet hebben gehoord van de SOLID-principes (wij . — Vert.) of van objectgeoriënteerd programmeren (OOP), of ze hebben er wel van gehoord maar gebruiken ze niet in de praktijk. In dit artikel worden de voordelen van OOP-principes beschreven die de ontwikkelaar helpen in zijn dagelijkse werk. Sommige zijn goed bekend, andere minder, zodat het artikel nuttig zal zijn voor zowel beginners als ervaren programmeurs.
Ter herinnering: voor alle lezers van «Habr» — korting van 10.000 roebels bij inschrijving voor elke Skillbox-cursus met de promotiecode «Habr».
Skillbox raadt aan: Online opleidingscursus .
DRY (Don’t Repeat Yourself)
Een vrij eenvoudig principe, waarvan de essentie duidelijk is uit de naam: «Herhaal jezelf niet». Voor een programmeur betekent dit de noodzaak om duplicerende code te vermijden en ook de mogelijkheid om abstractie in het werk te gebruiken.
Als er in de code twee herhalende delen zijn, moeten ze worden samengevoegd tot één methode. Als een hardcoded waarde meer dan eens wordt gebruikt, moet deze worden omgevormd tot een openbare constante.
Dit is nodig om de code te vereenvoudigen en het onderhoud ervan gemakkelijker te maken, wat de belangrijkste taak van OOP is. Overmatig combineren is ook niet aan te raden, aangezien dezelfde code niet kan worden gecontroleerd met zowel OrderId als SSN.
Incapsulatie van wijzigingen
Softwareproducten van de meeste bedrijven evolueren voortdurend. Dit betekent dat er wijzigingen in de code moeten worden aangebracht, deze moet worden onderhouden. Je kunt je leven makkelijker maken door middel van incapsulatie. Dit stelt je in staat om de bestaande codebasis efficiënter te testen en te onderhouden. .
Als je in Java schrijft, dan .
Principe van openheid/sluitheid
Dit principe is gemakkelijk te onthouden door de volgende uitspraak te lezen: «Software-entiteiten (klassen, modules, functies, etc.) moeten open zijn voor uitbreiding, maar gesloten voor wijziging». In de praktijk betekent dit dat ze hun gedrag kunnen wijzigend zonder de oorspronkelijke code aan te passen.
Het principe is belangrijk wanneer veranderingen in de oorspronkelijke code een herziening, unit-testing en andere procedures vereisen. Code die onder het openheid/sluitheid-principe valt, verandert niet bij uitbreiding, zodat er veel minder problemen mee zijn.
Dit is een voorbeeld van code die dit principe schendt.
Als er iets aan gewijzigd moet worden, kost dat veel tijd, omdat alle delen van de code die verband houden met het betreffende fragment veranderd moeten worden.
Overigens is open-geslotenheid een van de SOLID-principes.
Het principe van unieke verantwoordelijkheid (SRP)
Een ander principe uit de SOLID-set. Het stelt dat 'er slechts één reden is om de klasse te veranderen'. Een klasse lost slechts één probleem op. Het kan meerdere methoden hebben, maar elke methode wordt alleen gebruikt om een gemeenschappelijk probleem op te lossen. Alle methoden en eigenschappen moeten hier alleen voor dienen.
De waarde van dit principe ligt in het verminderen van de afhankelijkheid tussen individuele softwarecomponenten en de code. Als er meer dan één functionaliteit aan een klasse wordt toegevoegd, introduceert dit een afhankelijkheid tussen twee functies. Als je er een wijzigt, is de kans groot dat je de andere, die met de eerste verbonden is, verpest. Dit betekent een toename van het aantal testcycli om alle problemen vooraf te identificeren.
Het principe van afhankelijkheidsinversie (DIP)
Hierboven is een voorbeeld van code gegeven waarbij AppManager afhankelijk is van EventLogWriter, dat op zijn beurt nauw verbonden is met AppManager. Als er een andere manier nodig is om een melding te tonen, of het nu een push, SMS of e-mail is, moet de klasse AppManager worden gewijzigd.
Het probleem kan worden opgelost met DIP. In plaats van AppManager vragen we EventLogWriter op, dat via het framework zal worden ingevoerd.
DIP maakt het mogelijk om afzonderlijke modules probleemloos door andere te vervangen door de afhankelijkheidsmodule te wijzigen. Dit stelt je in staat om één module te wijzigen zonder invloed op de anderen.
Compositie in plaats van erfelijkheid
Er zijn twee hoofdmanieren om code her te gebruiken: erfelijkheid en compositie, en beide hebben zowel voordelen als nadelen. Meestal gaat de voorkeur uit naar de tweede, omdat deze flexibeler is.
Compositie maakt het mogelijk om het gedrag van een klasse tijdens runtime te wijzigen door zijn eigenschappen in te stellen. Polymorfisme wordt gebruikt bij het implementeren van interfaces, wat een flexibeler implementatie biedt.
Zelfs 'Effective Java' van Joshua Bloch adviseert om de voorkeur te geven aan compositie in plaats van erfelijkheid.
Het substitutieprincipe van Barbara Liskov (LSP)
Een ander principe uit de SOLID-toolkit. Het stelt dat subtypes vervangbaar moeten zijn voor het supertype. Dit betekent dat methoden en functies die werken met de superklasse, zonder problemen moeten kunnen werken met zijn subklassen.
LSP is zowel gerelateerd aan het principe van enkele verantwoordelijkheden als aan het principe van gescheiden verantwoordelijkheden. Als een klasse meer functionaliteit biedt dan de subklasse, dan ondersteunt de laatste mogelijk niet sommige functies, wat dit principe schendt.
Hier is een codefragment dat in strijd is met LSP.
De methode area(Rectangle r) berekent de oppervlakte van een Rectangle. Het programma zal falen bij het uitvoeren van Square, omdat Square hier geen Rectangle is. Volgens het LSP-principe moeten functies die verwijzingen naar basis klassen gebruiken, in staat zijn om ook objecten van afgeleide klassen te gebruiken zonder extra instructies.
Dit principe, dat een specifieke definitie van subtype is, werd in 1987 voorgesteld door Barbara Liskov tijdens een conferentie in een hoofdlezing getiteld 'Gegevensabstractie en hiërarchie' — hier komt de naam vandaan.
Principe van gescheiden interfaces (ISP)
Weer een principe van SOLID. Volgens dit principe moet een interface die niet wordt gebruikt, niet worden geïmplementeerd. Het volgen van dit principe helpt het systeem flexibel en geschikt voor refactoring te blijven bij veranderingen in de logica.
Deze situatie komt vaak voor wanneer de interface meerdere functionaliteiten bevat, terwijl de klant er slechts één nodig heeft.
Aangezien het schrijven van een interface een complexe taak is, zal het na voltooiing problematisch zijn om deze te wijzigen zonder iets te verstoren.
Een voordeel van het ISP-principe in Java is dat alle methoden eerst moeten worden geïmplementeerd, en pas daarna kunnen ze door klassen worden gebruikt. Dit principe maakt het mogelijk om het aantal methoden te verlagen.
Programmeren voor interfaces, niet voor implementaties
Hier is alles duidelijk uit de naam. Het toepassen van dit principe leidt tot flexibele code die met elke nieuwe implementatie van de interface kan werken.
Gebruik het type interface voor variabelen, retourneertypes of het type van de methodeparameter. Voorbeeld — gebruik SuperClass in plaats van SubClass.
Dat wil zeggen:
List numbers = getNumbers();
En niet:
ArrayList numbers = getNumbers();
Hier is een praktische implementatie van wat hierboven is gezegd.
Principes van delegatie
Een veelvoorkomend voorbeeld zijn de methoden equals() en hashCode() in Java. Wanneer het nodig is om twee objecten te vergelijken, wordt deze actie gedelegeerd aan de overeenkomstige klasse in plaats van de client.
Het voordeel van het principe is het ontbreken van code duplicatie en de relatief eenvoudige aanpassing van gedrag. Het is ook toepasbaar op het delegëren van gebeurtenissen.
Al deze principes stellen ons in staat om flexibele, mooie en betrouwbare code te schrijven met een hoge cohesie en lage koppeling. Natuurlijk is theorie goed, maar om een ontwikkelaar echt de opgedane kennis te laten gebruiken, is praktijk nodig. De volgende stap na het beheersen van de principes van OOP kan zijn het bestuderen van ontwerppatronen om veelvoorkomende problemen in softwareontwikkeling op te lossen.
Skillbox raadt aan:
- Praktische cursus .
- Toegepaste online cursus .
- Praktische tweejarenopleiding .
Bron: habr.com
