Designmønster eksponert: Strategimønster



I denne bloggen vil vi avdekke Strategy Design Pattern, som brukes til å lage en utskiftbar familie av algoritmer som kan velges dynamisk.

'

Velkommen til det første innlegget i “Design Patterns Exposed” -serien. I denne serien skal vi avdekke hvert designmønster fra bunnen av.





Bare å kjenne et programmeringsspråk og dets konstruksjoner vil ikke gjøre deg til en bedre programmerer eller utvikler. Det krever kunnskap om designmønstre for å lage programvare som vil fungere i dag og også i fremtiden.

Mange utviklere har allerede kommet over de designproblemene du står overfor akkurat nå eller vil møte i fremtiden. De har spesifisert en standard måte å håndtere det problemet på. Så ved å bruke designmønstre får du fordelen av å bruke velprøvde teknikker.



Hvert designmønster er for å løse en bestemt type situasjon. Det kan være situasjoner der mer enn ett designmønster kan brukes.

De fleste av programmererne prøver bare å løse problemet de møter uten å bry seg om designmønstre, overflødig kode eller til og med tetkobling. Men gode programmerere starter annerledes. De tenker på dagens krav, fremtidige krav, vedlikehold av kode og gjenbrukbarhet av kode.

Gode ​​programmerere har ikke travelt med å starte kodingen når de først har fått kravene. De sitter og tenker på problemet med om designet deres vil fungere. Hvis ja, om det vil fungere etter 6 måneder, når kravene vil endres.



Gode ​​programmerere tar pennen og papiret og begynner å designe klassene sine og forholdet mellom klassene. De prøver å få løs kobling og høy kohesjon i designet, mens de gjør alt dette har de objektorienterte prinsipper i tankene. De går ikke inn på lavnivåkode umiddelbart. For å designe fleksibel og gjenbrukbar programvare, bør du følge denne tilnærmingen ellers vil du alltid finne deg selv å endre koden du hadde skrevet tidligere.

Det er bare en ting som er konstant i programvareindustrien, og det er Endring. Kravene vil helt sikkert endres. Så hvordan designer vi programvaren som koden din enkelt kan tilpasse seg fremtidige krav? For det må du begynne tidlig, og utforme det på en slik måte at fremtidige krav ikke bryter din forrige kode.

Hvordan kan jeg gjøre det?

Vel, det kan gjøres ved å følge designprinsipper og designmønstre basert på disse prinsippene.

Nå, la oss dykke ned i koding og komme i gang på reisen for å bli en bedre programmerer. I dette innlegget skal vi avdekke et av de viktigste mønstrene - Strategimønster .

Når jeg sier det viktigste, gjenspeiler det det vanlige problemet som løses av Strategimønster.

Hva er strategimønster?

Her er definisjonen rett fra boken ‘Gang of Four’: “Strategimønsteret brukes til å lage en utskiftbar familie av algoritmer som den nødvendige prosessen velges fra i løpetid”.

I tilfelle du er detikke i stand til å forstå, ikke bekymre deg, vi skal forklare det i enenklereveifor at du skalforstå.

La oss først forstå problemet, og så vil vi se hvordan Strategimønster kan løse det.

I UML-diagrammet ovenfor har vi Animal abstract-klasse og to konkrete klasser, Dog and Bird, som strekker seg fra Animal super class.

Så la oss definere en abstrakt klasse for dyr og to konkrete klasser, hund og fugl.

Hva synes du om designen ovenfor? Det er en stor feil i designet vårt.

Alle dyrene kan ikke fly, som i tilfellet ovenfor, kan en hund ikke fly. Men fortsatt har den 'fly' oppførsel.

Vi gjorde en feil ved å skrive den abstrakte fly () -metoden i dyreklassen. Denne designen vil tvinge hver underklasse hund, fugl, pingvin, krokodille, gås osv. Til å implementere fly () -metoden.

Vi burde ha forstått at fly er en evne som ikke alle dyr vil ha. Ved å tilby fly () -metoden i Animal Abstract-klassen har vi satt flygeevnen i alle underklasser som ikke er riktig for alle underklasser av dyr.

Du tenker kanskje hva som er problemet med å implementere flymetoden i underklassene. Selv om du kan implementere fly () -metoden i ikke-flygende dyrekategorier for å bare skrive ut 'Jeg kan ikke fly'. Men problemet er at du fortsatt gir flueadferd til dyr som ikke flyr. Dette er ikke riktig.

Hvordan føles det å kalle dog.fly () eller crocodile.fly ().

Så nå har vi forstått at designet vårt ikke er riktig, og vi bør fjerne fly () -metoden fra dyrekategorien.

Hva er den andre måten å designe klassene våre på en slik måte at vårt design ikke tvinger alle dyrekategorier til å ha flueadferd.

En løsning som umiddelbart kommer til å tenke er at vi kan lage et flygrensesnitt med flymetode, og bare dyr som kan fly vil implementere det flygrensesnittet. På denne måten vil vi ikke håndheve alle dyrekategorier for å definere en flueadferd. Så la oss kode denne designtilnærmingen.

Nå vil dyreklassen vår se ut som koden nedenfor etter å ha fjernet fluemetoden fra dyreklassen.

La oss nå definere Flying-grensesnittet

Nå vil hundeklassen endressomkoden nedenfor, og den trenger ikke å ha flueadferd.

La oss se noen av dyrekategoriene våre med dyreoppførsel.

Vi har løst vårt forrige problem, men vi kom inn i et nytt problem, og det er 'Code Duplication'.

Si, vi kommer til å ha 100 forskjellige underklasser for flygende dyr. Vi må duplisere koden for flyadferd siden flygrensesnitt ikke kan gi noen implementering for flyadferd, og hvis vi senere vil endre implementeringen av fly () -metoden i en underklasse, må vi åpne den klassen og endre koden, som er dårlig. Vi mangler noe stort, og det vil si at vi ikke kan endre flyoppførselen til en klasse i løpetid.

Men ikke bekymre deg, Strategimønster er der for å få deg ut av dette problemet.

Så la oss omforme koden vår for å bruke Strategimønster.

Flygrensesnitt vil forbli det samme som det er. Nå, i stedet for at hver flygende underklasse implementerer selve flygrensesnittet, skal vi definere separate konkrete klasser som vil implementere ulik flygedrift. La oss se hvordan vi gjør det.

Så hvordan det hele fungerer, la oss se TestClass

javascript lengde på en matrise

Ved å bruke Strategimønster kan vi nå endre flygedriften til ethvert dyr i løpetid, og det er uten å håndheve noen underklasser for å spesifisere selve flygedriften.

Når skal jeg bruke strategimønster?

Når du vil være i stand til å endre oppførselen på kjøretid dynamisk.

For å være sikker på at du forstår strategimønsteret tydelig, la oss ta et annet eksempel.

I den ovennevnte medarbeiderklassen setter vi lønnen til den ansatte avhengig av hans / hennes betegnelse. Hvis en ansatt er en 'praktikant', legger vi til 10% bonus i grunnlønnen for å beregne den faktiske lønnen.

Hvis en ansatt er en “webutvikler”, legger vi til 20% bonus i grunnlønnen for å beregne den faktiske lønnen og lignende prosess følger for andre typer ansatte. Selv om algoritmen vår for å beregne den faktiske lønnen er veldig enkel for å gjøre det lettere å forstå, men mesteparten av tiden, inneholder den mange sammenligninger og beregninger.

Så, hva er galt med arbeidsklassekode?

Vel, koden for å beregne lønn (getPay ()) er statisk. Anta at jeg vil endre bonusen for “Intern” fra 10% til 14%. Jeg må åpne koden for de ansatte og endre den.

Og et annet problem er at jeg ikke kan endre en ansattes lønnsalgoritme i løpetid. Så hvordan gjør jeg det? Strategimønster brukes spesielt til å håndtere denne typen problemer.

La oss omformulere koden for å bruke Strategimønster.

Jeg skal definere flere algoritmer for å beregne lønn. Da vil jeg kunne bruke noen av disse algoritmene til å beregne lønn ved kjøretid.

La oss nå se hvordan ansatteklassen kommer til å endres.

Merk: Jeg har fjernet lønnsberegningslogikken fra medarbeiderklassen og opprettet en angitt PayAlgorithm () -metode som jeg vil sette den PayAlgorithm som jeg vil bruke til lønnsberegning.

Dette vil gi meg fleksibiliteten til å beregne lønnen ved å spesifisere en hvilken som helst PayAlgorithm dynamisk ved kjøretid. Legg også merke til at hvis jeg senere må endre logikk for lønnsberegning, kan jeg opprette en ny PayAlgorithm og bruke den til å beregne lønnen. Jeg trenger ikke å endre den forrige koden, er det ikke bra?

Så la oss se at det fungerer.

Jeg håper du forsto strategimønsteret veldig bra. Den beste måten å lære noe på er å øve.

Hvis du har spørsmål knyttet til strategimønster eller annet mønster, kan du legge igjen spørsmålene nedenfor.

Se opp for neste innlegg, hvor vi vil avdekke et av de mest populære designmønstrene, Factory Pattern.

Inntil da kan du laste ned kodespillet med det og sørge for at du sementerer strategimønsteret i hodet ditt.

Har du et spørsmål til oss? Nevn dem i kommentarfeltet, så kommer vi tilbake til deg.

Relaterte innlegg: