De 7 vigtigste softwaredesignmønstre

For en omfattende dybdyb i emnet Software Design Patterns, se Software Design Patterns: Best Practices for Developers, oprettet af C.H. Afzal, en veteran softwareingeniør med flere års erfaring hos Netflix, Microsoft og Oracle. Meget af nedenstående er opsummeret fra hans kursus.

Hvorfor designe mønstre?

Designmønstre er blevet genstand for en del kontroverser i programmeringsverdenen i nyere tid, stort set på grund af deres opfattede 'overforbrug', der fører til kode, der kan være sværere at forstå og styre.

Det er vigtigt at forstå, at designmønstre aldrig var beregnet til at blive hacket sammen genveje, der skal anvendes på en tilfældig 'one-size-past-all' måde på din kode. Der er i sidste ende ingen erstatning for ægte problemløsningsevner inden for software engineering.

Faktum er dog, at designmønstre kan være utroligt nyttige, hvis de bruges i de rigtige situationer og af de rigtige grunde. Når de bruges strategisk, kan de gøre en programmerer markant mere effektiv ved at lade dem undgå at opfinde det sproglige hjul i stedet for ved hjælp af metoder, der allerede er raffineret af andre. De giver også et nyttigt fælles sprog til at konceptualisere gentagne problemer og løsninger, når man diskuterer med andre eller administrerer kode i større teams.

Når det er sagt, er et vigtigt advarsel at sikre, at hvordan og hvorfor bag hvert mønster også forstås af udvikleren.

Uden videre (i almindelig rækkefølge fra mest til mindst):

De vigtigste designmønstre

  1. Singleton

Singleton-mønsteret bruges til at begrænse oprettelsen af ​​en klasse til kun et objekt. Dette er gavnligt, når der er behov for et (og kun et) objekt for at koordinere handlinger på tværs af systemet. Der er adskillige eksempler på, hvor der kun skal findes et enkelt eksempel af en klasse, herunder cacher, trådpuljer og registre.

Det er trivielt at indlede et objekt fra en klasse - men hvordan sikrer vi, at kun et objekt nogensinde bliver skabt? Svaret er at gøre konstruktøren 'privat' til den klasse, vi agter at definere som en singleton. På den måde er det kun klassens medlemmer, der har adgang til den private konstruktør og ingen andre.

Vigtig overvejelse: Det er muligt at underklasse en singleton ved at gøre konstruktøren beskyttet i stedet for privat. Dette kan være passende under nogle omstændigheder. En fremgangsmåde, der tages i disse scenarier, er at oprette et register over singletoner i underklasserne, og getInstance-metoden kan indtaste en parameter eller bruge en miljøvariabel til at returnere det ønskede singleton. Registret opretholder derefter en kortlægning af strengnavne til singleton-objekter, som du kan få adgang til efter behov.

2. Fabriksmetode

En normal fabrik producerer varer; en softwarefabrik producerer objekter. Og ikke bare det - det gør det uden at specificere den nøjagtige klasse af det objekt, der skal oprettes. For at opnå dette oprettes objekter ved at kalde en fabriksmetode i stedet for at kalde en konstruktør.

Normalt sker objektoprettelse i Java sådan:

SomeClass someClassObject = new SomeClass ();

Problemet med ovenstående tilgang er, at koden, der bruger SomeClass-objektet, pludselig nu afhænger af den konkrete implementering af SomeClass. Der er ikke noget galt i at bruge nye til at oprette objekter, men det kommer med bagagen til tæt kobling af vores kode til den konkrete implementeringsklasse, som lejlighedsvis kan være problematisk.

3. Strategi

Strategimønsteret tillader gruppering af relaterede algoritmer under en abstraktion, som tillader at skifte en algoritme eller politik til en anden uden at ændre klienten. I stedet for direkte at implementere en enkelt algoritme, modtager koden runtime-instruktioner, der specificerer hvilken af ​​gruppen af ​​algoritmer, der skal køres.

4. Observatør

Dette mønster er en en-til-mange-afhængighed mellem objekter, så når et objekt ændrer tilstand, bliver alle dets afhængige underrettet. Dette gøres typisk ved at kalde en af ​​deres metoder.

For enkelheds skyld skal du tænke over, hvad der sker, når du følger nogen på Twitter. Du beder i det væsentlige Twitter om at sende dig (observatøren) tweet-opdateringer af den person (emnet), du fulgte. Mønsteret består af to skuespillere, observatøren, der er interesseret i opdateringerne, og emnet, der genererer opdateringerne.

Et emne kan have mange observatører og er et forhold til mange. Imidlertid er en observatør fri til at abonnere på opdateringer fra andre emner. Du kan abonnere på nyhedsfeed fra en Facebook-side, hvilket ville være emnet, og hver gang siden har et nyt indlæg, vil abonnenten se det nye indlæg.

Nøgleovervejelse: I tilfælde af mange emner og få observatører, hvis hvert enkelt person gemmer sine observatører separat, øger det lagringsomkostningerne, da nogle emner opbevarer den samme observatør flere gange.

5. Builder

Som navnet antyder, bruges et buildermønster til at bygge objekter. Undertiden kan objekterne, vi skaber, være komplekse, sammensat af flere underobjekter eller kræve en detaljeret konstruktionsproces. Øvelsen med at skabe komplekse typer kan forenkles ved at bruge bygmønsteret. En sammensat eller et samlet objekt er det, som en builder generelt bygger.

Nøgleovervejelse: Builder-mønsteret kan synes at ligner det 'abstrakte fabriksmønster', men en forskel er, at bygmester-mønsteret skaber et objekt trin for trin, mens det abstrakte fabriksmønster returnerer objektet på én gang.

6. Adapter

Dette gør det muligt for ukompatible klasser at arbejde sammen ved at konvertere interface til en klasse til en anden. Tænk på det som en slags oversætter: når to stater af stater, der ikke taler et fælles sprog, mødes, sidder normalt en tolk mellem de to og oversætter samtalen, hvilket muliggør kommunikation.

Hvis du har to applikationer, hvor den ene spytter ud som XML og den anden kræver JSON-input, skal du bruge en adapter mellem de to for at få dem til at fungere problemfrit.

7. Stat

Tilstandsmønsteret indkapsler de forskellige tilstande, en maskine kan være i, og tillader et objekt at ændre dens opførsel, når dens interne tilstand ændres. Maskinen eller konteksten, som det kaldes i mønster-tale, kan have handlinger truffet på den, der driver den til forskellige tilstande. Uden brug af mønsteret bliver koden ufleksibel og fyldt med ellers ellers betingelser.

Vil du fortsætte med at lære?

Med software designmønstre: Bedste praksis for udviklere har du chancen for at gøre mere end bare at læse teorien. Du vil være i stand til at dykke dybt ned i virkelige problemer og forstå praktiske løsninger med eksempler på det virkelige liv.

Kurset er baseret på den populære bog af Gang of Four, men præsenteret i et interaktivt, let at fordøje format. Du mestrer de 23 berømte designmønstre fra bogen interaktivt, lærer de korrekte anvendelser af de 3 nøglemønstertyper (kreative, strukturelle og adfærdsmæssige) og lærer at integrere disse designmønstre i dine egne projekter.

Tjek det nu.

Oprindeligt offentliggjort på blog.educative.io den 7. november 2018.