{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principes van objectgeori\u00ebnteerd programmeren die elke ontwikkelaar moet kennen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nIk kom vrij vaak ontwikkelaars tegen die niet hebben gehoord van de SOLID-principes (wij hebben ze hier in detail besproken<\/a><\/noindex>. \u2014 Vert.) of van objectgeori\u00ebnteerd 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.
\n<\/a><\/noindex><\/p>\n

Ter herinnering:<\/b> voor alle lezers van \u00abHabr\u00bb \u2014 korting van 10.000 roebels bij inschrijving voor elke Skillbox-cursus met de promotiecode \u00abHabr\u00bb.<\/i><\/p>\n

Skillbox raadt aan:<\/b> Online opleidingscursus \u00abJava-ontwikkelaar\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nEen vrij eenvoudig principe, waarvan de essentie duidelijk is uit de naam: \u00abHerhaal jezelf niet\u00bb. Voor een programmeur betekent dit de noodzaak om duplicerende code te vermijden en ook de mogelijkheid om abstractie in het werk te gebruiken.<\/p>\n

Als er in de code twee herhalende delen zijn, moeten ze worden samengevoegd tot \u00e9\u00e9n methode. Als een hardcoded waarde meer dan eens wordt gebruikt, moet deze worden omgevormd tot een openbare constante.<\/p>\n

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.<\/p>\n

Incapsulatie van wijzigingen<\/h3>\n

\nSoftwareproducten 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\u00ebnter te testen en te onderhouden. Hier is een van de voorbeelden<\/a><\/noindex>.<\/p>\n

Als je in Java schrijft, dan wijst standaard private toe aan methoden en variabelen<\/a><\/noindex>.<\/p>\n

Principe van openheid\/sluitheid<\/h3>\n

\nDit principe is gemakkelijk te onthouden door de volgende uitspraak te lezen: \u00abSoftware-entiteiten (klassen, modules, functies, etc.) moeten open zijn voor uitbreiding, maar gesloten voor wijziging\u00bb. In de praktijk betekent dit dat ze hun gedrag kunnen wijzigend zonder de oorspronkelijke code aan te passen.<\/p>\n

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.<\/p>\n

Dit is een voorbeeld van code die dit principe schendt.<\/p>\n

\"10
\n
\nAls 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.<\/p>\n

Overigens is open-geslotenheid een van de SOLID-principes.<\/p>\n

Het principe van unieke verantwoordelijkheid (SRP)<\/h3>\n

\nEen ander principe uit de SOLID-set. Het stelt dat 'er slechts \u00e9\u00e9n reden is om de klasse te veranderen'. Een klasse lost slechts \u00e9\u00e9n 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. <\/p>\n

\"10
\n
\nDe waarde van dit principe ligt in het verminderen van de afhankelijkheid tussen individuele softwarecomponenten en de code. Als er meer dan \u00e9\u00e9n 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.<\/p>\n

Het principe van afhankelijkheidsinversie (DIP)<\/h3>\n

\n\"10
\n
\nHierboven 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.<\/p>\n

Het probleem kan worden opgelost met DIP. In plaats van AppManager vragen we EventLogWriter op, dat via het framework zal worden ingevoerd.<\/p>\n

DIP maakt het mogelijk om afzonderlijke modules probleemloos door andere te vervangen door de afhankelijkheidsmodule te wijzigen. Dit stelt je in staat om \u00e9\u00e9n module te wijzigen zonder invloed op de anderen.<\/p>\n

Compositie in plaats van erfelijkheid<\/h3>\n

\n\"10Er 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.<\/p>\n

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.<\/p>\n

Zelfs 'Effective Java' van Joshua Bloch adviseert om de voorkeur te geven aan compositie in plaats van erfelijkheid.<\/p>\n

Het substitutieprincipe van Barbara Liskov (LSP)<\/h3>\n

\nEen 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.<\/p>\n

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.<\/p>\n

Hier is een codefragment dat in strijd is met LSP.<\/p>\n

\"10
\n
\nDe 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.<\/p>\n

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\u00ebrarchie' \u2014 hier komt de naam vandaan.<\/p>\n

Principe van gescheiden interfaces (ISP)<\/h3>\n

\nWeer een principe van SOLID. Volgens dit principe moet een interface die niet wordt gebruikt, niet worden ge\u00efmplementeerd. Het volgen van dit principe helpt het systeem flexibel en geschikt voor refactoring te blijven bij veranderingen in de logica.<\/p>\n

Deze situatie komt vaak voor wanneer de interface meerdere functionaliteiten bevat, terwijl de klant er slechts \u00e9\u00e9n nodig heeft.<\/p>\n

Aangezien het schrijven van een interface een complexe taak is, zal het na voltooiing problematisch zijn om deze te wijzigen zonder iets te verstoren.<\/p>\n

Een voordeel van het ISP-principe in Java is dat alle methoden eerst moeten worden ge\u00efmplementeerd, en pas daarna kunnen ze door klassen worden gebruikt. Dit principe maakt het mogelijk om het aantal methoden te verlagen.<\/p>\n

\"10
\n <\/p>\n

Programmeren voor interfaces, niet voor implementaties<\/h3>\n

\nHier 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.<\/p>\n

Gebruik het type interface voor variabelen, retourneertypes of het type van de methodeparameter. Voorbeeld \u2014 gebruik SuperClass in plaats van SubClass.<\/p>\n

Dat wil zeggen:<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

En niet:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Hier is een praktische implementatie van wat hierboven is gezegd.<\/p>\n

\"10
\n <\/p>\n

Principes van delegatie<\/h3>\n

\nEen 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.<\/p>\n

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\u00ebren van gebeurtenissen.<\/p>\n

\"10
\n
\nAl 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.<\/p>\n

Skillbox raadt aan:<\/b><\/p>\n