De 7 viktigste mønsterene for programvaredesign

For et omfattende dypdykk i emnet Software Design Patterns, sjekk ut Software Design Patterns: Best Practices for Developers, laget av C.H. Afzal, en veteran programvareingeniør med flere års erfaring hos Netflix, Microsoft og Oracle. Mye av det nedenfor er oppsummert fra hans kurs.

Hvorfor designe mønstre?

Designmønstre har blitt gjenstand for en del kontroverser i programmeringsverdenen i nyere tid, i stor grad på grunn av at deres opplevde ‘overbruk’ fører til kode som kan være vanskeligere å forstå og administrere.

Det er viktig å forstå at designmønstre aldri var ment å bli hacket sammen snarveier for å bli brukt på en tilfeldig 'one-size-fit-all' måte på koden din. Det er til slutt ingen erstatning for ekte problemløsningsevne innen programvareteknikk.

Faktum gjenstår imidlertid at designmønstre kan være utrolig nyttige hvis de brukes i riktige situasjoner og av de rette grunnene. Når de brukes strategisk, kan de gjøre en programmerer betydelig mer effektiv ved å la dem unngå å oppfinne det ordspråklige hjulet, i stedet for å bruke metoder som allerede er raffinert av andre. De gir også et nyttig fellesspråk for å konseptualisere gjentatte problemer og løsninger når du diskuterer med andre eller administrerer kode i større team.

Når det er sagt, er et viktig advarsel å sikre at hvordan og hvorfor bak hvert mønster også forstås av utvikleren.

Uten videre (i generell rekkefølge, fra mest til minst):

De viktigste designmønstrene

  1. Singleton

Singletonmønsteret brukes til å begrense opprettelsen av en klasse til bare ett objekt. Dette er gunstig når ett (og bare ett) objekt er nødvendig for å koordinere handlinger på tvers av systemet. Det er flere eksempler på hvor bare en enkelt forekomst av en klasse skal eksistere, inkludert cacher, trådbassenger og registre.

Det er trivielt å sette i gang et objekt av en klasse - men hvordan sikrer vi at bare ett objekt noensinne blir opprettet? Svaret er å gjøre konstruktøren ‘privat’ til klassen vi har tenkt å definere som singleton. På den måten er det bare medlemmene i klassen som har tilgang til den private konstruktøren og ingen andre.

Viktig hensyn: Det er mulig å underklasse en singleton ved å gjøre konstruktøren beskyttet i stedet for privat. Dette kan være passende under noen omstendigheter. En tilnærming tatt i disse scenariene er å lage et register over singletoner av underklassene, og getInstance-metoden kan ta inn en parameter eller bruke en miljøvariabel for å returnere ønsket singleton. Registret opprettholder deretter en kartlegging av strengnavn til singleton-objekter, som du kan få tilgang til etter behov.

2. Fabrikkmetode

En normal fabrikk produserer varer; en programvarefabrikk produserer objekter. Og ikke bare det - det gjør det uten å spesifisere den eksakte klassen til objektet som skal opprettes. For å oppnå dette blir objekter opprettet ved å kalle en fabrikkmetode i stedet for å kalle en konstruktør.

Vanligvis skjer objektskaping i Java slik:

SomeClass someClassObject = new SomeClass ();

Problemet med fremgangsmåten ovenfor er at koden som bruker objektet til SomeClass, plutselig nå blir avhengig av den konkrete implementeringen av SomeClass. Det er ingenting galt med å bruke nye for å lage objekter, men det kommer med bagasjen for å tette koden vår til den konkrete implementeringsklassen, som tidvis kan være problematisk.

3. Strategi

Strategimønsteret gjør det mulig å gruppere relaterte algoritmer under en abstraksjon, som gjør det mulig å skifte ut en algoritme eller policy for en annen uten å endre klienten. I stedet for direkte å implementere en enkelt algoritme, mottar koden runtime-instruksjoner som spesifiserer hvilken av gruppen av algoritmer som skal kjøres.

4. Observatør

Dette mønsteret er en-til-mange-avhengighet mellom objekter, slik at når ett objekt endrer tilstand, blir alle avhengige varslet. Dette gjøres vanligvis ved å kalle en av metodene deres.

For enkelhets skyld, tenk på hva som skjer når du følger noen på Twitter. Du ber i hovedsak Twitter om å sende deg (observatøren) tweetoppdateringer av personen (emnet) du fulgte. Mønsteret består av to skuespillere, observatøren som er interessert i oppdateringene og emnet som genererer oppdateringene.

Et fag kan ha mange observatører og er et forhold til mange. Imidlertid er en observatør fri til å abonnere på oppdateringer fra andre fag også. Du kan abonnere på nyhetsstrøm fra en Facebook-side, som vil være emnet, og når siden har et nytt innlegg, vil abonnenten se det nye innlegget.

Sentralt hensyn: Hvis det er mange fagpersoner og få observatører, vil hvert enkelt individ lagre observatørene hver for seg, vil det øke lagringskostnadene, da noen personer lagrer den samme observatøren flere ganger.

5. Byggmester

Som navnet tilsier, brukes et byggmønster for å bygge objekter. Noen ganger kan objektene vi lager være sammensatte, bestå av flere underobjekter eller kreve en utførlig byggeprosess. Øvelsen med å lage komplekse typer kan forenkles ved å bruke byggemønsteret. En sammensatt eller et samlet objekt er det en byggherre generelt bygger.

Sentralt hensyn: Byggemønsteret kan virke likt det 'abstrakte fabrikkmønsteret', men en forskjell er at byggmønsteret oppretter et objekt trinn for trinn, mens det abstrakte fabrikkmønsteret returnerer objektet på en gang.

6. Adapter

Dette gjør at inkompatible klasser kan jobbe sammen ved å konvertere grensesnittet til en klasse til en annen. Tenk på det som en slags oversetter: når to statsoverhoder som ikke snakker et felles språk, møtes vanligvis en tolk mellom de to og oversetter samtalen, og dermed muliggjør kommunikasjon.

Hvis du har to applikasjoner, med den ene spytte ut som XML og den andre som krever JSON-inngang, trenger du en adapter mellom de to for å få dem til å fungere sømløst.

7. Staten

Tilstandsmønsteret omslutter de forskjellige tilstandene en maskin kan være i, og lar et objekt endre sin oppførsel når dens indre tilstand endres. Maskinen eller konteksten, som det kalles i mønster-tale, kan ha handlinger som er utført for å drive den til forskjellige tilstander. Uten bruk av mønsteret blir koden ufleksibel og strødd med ellers andre balsam.

Vil du fortsette å lære?

Med programvaredesignmønstre: beste praksis for utviklere har du sjansen til å gjøre mer enn bare å lese teorien. Du vil kunne dykke dypt ned i virkelige problemer og forstå praktiske løsninger med kodeeksempler fra det virkelige liv.

Kurset er basert på den populære boken fra Gang of Four, men presentert i et interaktivt, lettfattelig format. Du mestrer de 23 berømte designmønstrene fra boken interaktivt, lærer de riktige anvendelsene av de tre viktige designmønstertypene (kreative, strukturelle og atferdsmessige) og lærer å integrere disse designmønstrene i dine egne prosjekter.

Sjekk det ut nå.

Opprinnelig publisert på blog.educative.io 7. november 2018.