'
Velkommen til det første indlæg i “Design Patterns Exposed” -serien. I denne serie skal vi afdække hvert designmønster fra bunden.
Blot at kende et programmeringssprog og dets konstruktioner vil ikke gøre dig til en bedre programmør eller udvikler. Det kræver viden om designmønstre for at skabe software, der fungerer i dag og også i fremtiden.
Mange udviklere har allerede stødt på de designproblemer, som du står over for lige nu eller vil stå over for i fremtiden. De har angivet en standard måde at håndtere dette problem på. Så ved at bruge designmønstre får du fordelen ved at bruge gennemprøvede teknikker.
Hvert designmønster er til løsning af en bestemt situation, der kan være situationer, hvor mere end et designmønster kan bruges.
De fleste af programmørerne prøver bare at løse det problem, de står over for uden at bekymre sig om designmønstre, overflødig kode eller endda tæt kobling. Men gode programmører starter anderledes. De tænker på nutidens krav, fremtidige krav, vedligeholdelse af kode og genbrugelighed af kode.
Gode programmører har ikke travlt med at begynde at kode, når de først har fået kravene. De sidder og tænker over problemet med, om deres design fungerer. Hvis ja, om det fungerer efter 6 måneder, når kravene ændres.
forskellen mellem final endelig og finalize
Gode programmører tager deres pen og papir og begynder at designe deres klasser og forholdet mellem klasser. De forsøger at få løs kobling og høj samhørighed i deres design, mens de gør alle disse, har de objektorienterede principper i tankerne. De går ikke ind i lavkodekode med det samme. For at designe fleksibel og genanvendelig software skal du følge denne tilgang, ellers vil du altid finde dig selv at ændre kode, som du havde skrevet tidligere.
Der er kun en ting, der er konstant i softwareindustrien, og det er Lave om. Kravene vil helt sikkert ændre sig. Så hvordan designer vi den software, som din kode let kan tilpasse sig fremtidige krav? Til det skal du starte tidligt og designe det på en sådan måde, at fremtidige krav ikke bryder din tidligere kode.
Hvordan kan jeg gøre det?
Nå, det kan gøres ved at følge designprincipper og designmønstre baseret på disse principper.
Lad os nu dykke ned i kodning og komme i gang på rejsen for at blive en bedre programmør. I dette indlæg vil vi afdække et af de vigtigste mønstre - Strategimønster .
Når jeg siger det vigtigste, reflekterer det over det almindelige problem, der løses ved strategimønster.
Hvad er strategimønster?
Her er definitionen direkte fra 'Gang of Four' bogen: 'Strategimønsteret bruges til at skabe en udskiftelig familie af algoritmer, hvorfra den krævede proces vælges ved kørsel”.
Hvis du erikke i stand til at forstå, skal du ikke bekymre dig, vi vil forklare det i enenklerevejfor dig atforstå.
Lad os først forstå problemet, og så vil vi se, hvordan strategimønster kan løse det.
I ovenstående UML-diagram har vi Animal Abstract-klasse og to konkrete klasser, Dog og Bird, der strækker sig fra Animal super-klasse.
Så lad os definere en animalsk abstrakt klasse og to konkrete klasser, hund og fugl.
Hvad synes du om ovenstående design? Der er en stor fejl i vores design.
Alle dyr kan ikke flyve, som i ovenstående tilfælde kan en hund ikke flyve. Men stadig har det 'fly' opførsel.
Vi lavede en fejl ved at skrive den abstrakte fly () -metode inden for dyreklassen. Dette design vil tvinge hver underklasse hund, fugl, pingvin, krokodille, gås osv. Til at implementere fly () -metoden.
Vi skulle have forstået, at flyvning er en evne, som ikke alle dyr har. Ved at tilbyde fly () -metoden i Animal Abstract-klassen har vi indstillet flyveevnen i alle underklasser, som ikke er korrekt for alle underklasser af dyr.
Du tænker måske, hvad der er problemet med at implementere flyve-metoden i underklasserne. Selvom du kan implementere fly () -metoden i de ikke-flyvende dyrekategorier for bare at udskrive 'Jeg kan ikke flyve'. Men problemet er, at du stadig giver flyveopførsel til ikke-flyvende dyr. Dette er ikke korrekt.
Hvordan føles det at kalde dog.fly () eller crocodile.fly ().
Så nu har vi forstået, at vores design ikke er korrekt, og vi skal fjerne fly () -metoden fra underklassen Animal.
Hvad er den anden måde at designe vores klasser på en måde, så vores design ikke tvinger alle dyrekategorier til at have flueopførsel.
En løsning, der straks kommer til at tænke på, er, at vi kan lave en flyvende grænseflade med flyve-metode, og kun dyr, der kan flyve, implementerer den flyvende grænseflade. På denne måde håndhæver vi ikke alle dyrekategorier til at definere en flyveopførsel. Så lad os kode denne designtilgang.
Nu vil vores dyreklasse se ud som nedenstående kode efter fjernelse af fluemetoden fra dyreklassen.
Lad os nu definere den flyvende grænseflade
Nu vil hundeklassen blive ændretsomkoden nedenfor, og den behøver ikke at have flyveopførsel.
Lad os se nogle af vores dyreunderklasser, der har flyvende adfærd.
Vi har løst vores tidligere problem, men vi kom ind i et nyt problem, og det er 'Code Duplication'.
Sig, vi vil have 100 forskellige flyvende dyrekategorier. Vi er nødt til at duplikere koden for flyveopførsel, da flyvegrænsefladen ikke kan give nogen implementering for flyveopførsel, og hvis vi senere vil ændre implementeringen af fly () -metoden i en underklasse, bliver vi nødt til at åbne den klasse og ændre koden hvilket er dårligt. Vi mangler noget stort, og det vil sige, vi kan ikke ændre en klasses flyvende adfærd i løbetid.
Men rolig, strategimønster er der for at få dig ud af dette problem.
Så lad os omformulere vores kode for at bruge strategimønster.
Flyvende grænseflade forbliver den samme som den er. Nu, snarere end at hver flyvende underklasse implementerer selve flyvegrænsefladen, vil vi definere separate konkrete klasser, der vil implementere forskellig flyveopførsel. Lad os se, hvordan man gør det.
Så hvordan det hele fungerer, lad os se TestClass
Ved at bruge strategimønster er vi nu i stand til at ændre ethvert dyrs flyveopførsel i løbetid, og det er uden at håndhæve nogen underklasser til at specificere flyveopførslen selv.
Hvornår skal man bruge strategimønster?
Når du vil være i stand til at ændre adfærd dynamisk ved kørselstid.
opsæt formørkelse til java
Lad os tage et andet eksempel for at sikre, at du tydeligt forstår strategimønsteret.
I ovennævnte medarbejderklasse fastsætter vi lønningen til medarbejderen afhængigt af hans / hendes udpegelse. Hvis en medarbejder er en 'praktikant', tilføjer vi 10% bonus i grundlønnen for at beregne den faktiske løn.
Hvis en medarbejder er en 'webudvikler', tilføjer vi 20% bonus i grundlønnen for at beregne den faktiske løn, og den lignende proces følger for andre typer medarbejdere. Selvom vores algoritme til beregning af den faktiske lønning er meget enkel for at gøre det lettere at forstå, men det meste af tiden, indeholder den mange sammenligninger og beregninger.
Så hvad er der galt med medarbejderklassekoden?
Nå, koden til beregning af løn (getPay ()) er statisk. Antag, at jeg vil ændre bonusen for 'Intern' fra 10% til 14%. Jeg bliver nødt til at åbne koden for medarbejderklassen og ændre den.
Og et andet problem er, at jeg ikke kan ændre en medarbejderes lønningsalgoritme i løbetid. Så hvordan gør man det? Strategimønster bruges specifikt til at håndtere denne form for problem.
Lad os omformulere koden for at bruge strategimønster.
Jeg vil definere flere algoritmer til beregning af løn. Så vil jeg være i stand til at bruge nogen af disse algoritmer til at beregne løn ved kørselstid.
Lad os nu se, hvordan medarbejderklassen vil ændre sig.
Bemærk: Jeg har fjernet lønberegningslogikken fra medarbejderklassen og oprettet en sæt PayAlgorithm () -metode, hvorigennem jeg vil indstille den PayAlgorithm, som jeg vil bruge til lønberegning.
Dette giver mig fleksibiliteten til at beregne lønnen ved at angive en hvilken som helst PayAlgorithm dynamisk ved kørsel. Bemærk også, at hvis jeg senere skal ændre betalingsberegningslogikken, kan jeg oprette en ny PayAlgorithm og bruge den til at beregne lønnen. Jeg har ikke brug for at ændre den forrige kode, er det ikke fantastisk?
Så lad os se det arbejde.
Jeg håber, du forstod strategimønsteret meget godt. Den bedste måde at lære noget på er at øve.
Hvis du har spørgsmål vedrørende strategimønster eller andet mønster, skal du lade dine spørgsmål være nedenfor.
Hold øje med det næste indlæg, hvor vi vil afdække et af de mest populære designmønstre, fabriksmønster.
Indtil da kan du downloade kodespil med det og sørge for at cementere strategimønsteret i dit hoved.
Har du et spørgsmål til os? Nævn dem i kommentarfeltet, så vender vi tilbage til dig.
Relaterede indlæg: