Heel vaak kom ik ontwikkelaars tegen die nog nooit van de SOLID-principes hebben gehoord (wij . — Vert.) of objectgeoriënteerd programmeren (OOP), of ervan gehoord hebben, maar er in de praktijk geen gebruik van maken. Dit artikel beschrijft de voordelen van OOP-principes die de ontwikkelaar helpen bij zijn dagelijkse werk. Sommigen van hen zijn bekend, andere niet zozeer, dus het artikel zal nuttig zijn voor zowel beginners als ervaren programmeurs.
Herinnering: voor alle Habr-lezers - een korting van 10 roebel bij inschrijving voor een Skillbox-cursus met behulp van de Habr-promotiecode.
Skillbox beveelt aan: Educatieve online cursus .
DROOG (herhaal jezelf niet)
Een vrij eenvoudig principe, waarvan de essentie duidelijk blijkt uit de naam: “Herhaal jezelf niet.” Voor een programmeur betekent dit de noodzaak om dubbele code te vermijden, evenals de mogelijkheid om abstractie in zijn werk te gebruiken.
Als de code twee herhalende secties bevat, moeten deze in één methode worden gecombineerd. Als een hardgecodeerde waarde meer dan één keer wordt gebruikt, is het de moeite waard om deze naar een openbare constante te converteren.
Dit is nodig om de code te vereenvoudigen en gemakkelijker te onderhouden, wat het hoofddoel van OOP is. Je moet de unie ook niet te veel gebruiken, omdat dezelfde code niet door de verificatie komt met zowel de OrderId als het SSN.
Veranderingen inkapselen
De softwareproducten van de meeste bedrijven evolueren voortdurend. Dit betekent dat er wijzigingen in de code moeten worden aangebracht, deze moet worden ondersteund. U kunt uw leven gemakkelijker maken door inkapseling te gebruiken. Hierdoor kunt u uw bestaande codebasis efficiënter testen en onderhouden. .
Als je in Java schrijft, dan .
Open/gesloten principe
Dit principe kan gemakkelijk worden onthouden door de volgende verklaring te lezen: “Software-entiteiten (klassen, modules, functies, enz.) moeten open zijn voor uitbreiding, maar gesloten voor wijziging.” In de praktijk betekent dit dat zij hun gedrag kunnen laten veranderen zonder de broncode te veranderen.
Dit principe is belangrijk wanneer wijzigingen in de broncode coderevisie, unit-tests en andere procedures vereisen. Code die het open/gesloten-principe volgt, verandert niet wanneer deze wordt uitgebreid, dus er zijn veel minder problemen mee.
Hier is een voorbeeld van code die dit principe schendt.
Als je daarin iets moet veranderen, kost dat veel tijd, omdat alle delen van de code die verband houden met het gewenste fragment moeten worden gewijzigd.
Openheid-geslotenheid is overigens één van de principes van SOLID.
Single Responsibility Principle (SRP)
Nog een principe uit de SOLID-set. Er staat dat “er maar één oorzaak is die een verandering in de klasse teweegbrengt.” De klas lost slechts één probleem op. Het kan verschillende methoden hebben, maar elk ervan wordt alleen gebruikt om een veelvoorkomend probleem op te lossen. Alle methoden en eigenschappen zouden alleen dit moeten dienen.
De waarde van dit principe is dat het de koppeling tussen de individuele softwarecomponent en de code losser maakt. Als u meer dan één functionaliteit aan een klasse toevoegt, introduceert dit een relatie tussen de twee functies. Als u dus een van deze wijzigt, is de kans groot dat u de tweede, die verbonden is met de eerste, verpest. En dit betekent dat de testcycli moeten worden uitgebreid om alle problemen vooraf te identificeren.
Afhankelijkheid Inversie Principe (DIP)
Hierboven ziet u een codevoorbeeld waarbij AppManager afhankelijk is van EventLogWriter, dat op zijn beurt nauw gekoppeld is aan AppManager. Als u een andere manier nodig heeft om een melding weer te geven, of het nu push, sms of e-mail is, moet u de AppManager-klasse wijzigen.
Het probleem kan worden opgelost met behulp van DIP. In plaats van AppManager vragen we dus om een EventLogWriter, die via het framework wordt ingevoerd.
DIP maakt het mogelijk om individuele modules eenvoudig te vervangen door andere door de afhankelijkheidsmodule te wijzigen. Dit maakt het mogelijk om één module te wijzigen zonder de andere te beïnvloeden.
Samenstelling in plaats van overerving
Er zijn twee belangrijke manieren om code te hergebruiken: overerving en compositie, die beide hun eigen voor- en nadelen hebben. Meestal heeft de tweede de voorkeur omdat deze flexibeler is.
Composition geeft u de mogelijkheid om het gedrag van een klasse tijdens runtime te wijzigen door de eigenschappen ervan in te stellen. Bij het implementeren van interfaces wordt gebruik gemaakt van polymorfisme, wat een flexibelere implementatie oplevert.
Zelfs Effective Java van Joshua Bloch adviseert compositie boven overerving te verkiezen.
Barbara Liskov-substitutieprincipe (LSP)
Nog een principe uit de SOLID-toolkit. Er wordt gesteld dat subtypes substitueerbaar moeten zijn voor het supertype. Dat wil zeggen dat methoden en functies die met een superklasse werken, zonder problemen met zijn subklassen moeten kunnen werken.
LSP wordt geassocieerd met zowel het principe van enkele verantwoordelijkheid als het principe van gedeelde verantwoordelijkheid. Als een klasse meer functionaliteit biedt dan een subklasse, zal deze een deel van de functionaliteit niet ondersteunen, wat in strijd is met dit principe.
Hier is een stukje code dat LSP tegenspreekt.
De methode area(Rectangle r) berekent de oppervlakte van een rechthoek. Het programma crasht na het uitvoeren van Square, omdat Square hier geen rechthoek is. Volgens het LSP-principe moeten functies die verwijzingen naar basisklassen gebruiken, objecten van afgeleide klassen kunnen gebruiken zonder aanvullende instructies.
Dit principe, dat een specifieke definitie is van een subtype, werd voorgesteld door Barbara Liskov in een keynote van een conferentie uit 1987 getiteld ‘Data Abstraction and Hierarchy’, vandaar de naam.
Interfacescheidingsprincipe (ISP)
Nog een SOLID-principe. Volgens het rapport mag een interface die niet wordt gebruikt, niet worden geïmplementeerd. Door dit principe te volgen, blijft het systeem flexibel en geschikt voor refactoring wanneer er wijzigingen worden aangebracht in de bedieningslogica.
Meestal doet deze situatie zich voor wanneer de interface meerdere functies tegelijk bevat en de klant er slechts één nodig heeft.
Omdat het schrijven van een interface een moeilijke taak is, zal het een uitdaging zijn om deze te wijzigen nadat het werk is voltooid zonder iets kapot te maken.
Het 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. Daarom maakt het principe het mogelijk om het aantal methoden te verminderen.
Programmeren voor de interface, niet voor de implementatie
Alles hier is duidelijk uit de naam. Het toepassen van dit principe leidt tot het creëren van flexibele code die met elke nieuwe implementatie van de interface kan werken.
U moet het interfacetype gebruiken voor variabelen, retourtypen of het methode-argumenttype. Een voorbeeld is het gebruik van SuperClass in plaats van SubClass.
Dat is:
Lijstnummers= getNumbers();
Maar niet:
ArrayList-nummers = getNumbers();
Hier is een praktische implementatie van wat hierboven is besproken.
Delegatie principe
Een bekend 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 aan de client.
Het voordeel van het principe is dat er geen sprake is van duplicatie van code en dat het relatief eenvoudig is om gedrag te veranderen. Het geldt ook voor delegatie van evenementen.
Met al deze principes kun je flexibelere, mooiere en betrouwbaardere code schrijven met hoge cohesie en lage koppeling. Natuurlijk is theorie goed, maar wil een ontwikkelaar de opgedane kennis ook daadwerkelijk kunnen gebruiken, dan is praktijk nodig. Als u de OOP-principes eenmaal onder de knie heeft, kan uw volgende stap het leren van ontwerppatronen zijn om veelvoorkomende softwareontwikkelingsproblemen op te lossen.
Skillbox beveelt aan:
- Praktische cursus .
- Toegepaste online cursus .
- Tweejarige praktijkopleiding .
Bron: www.habr.com