'
Välkommen till det första inlägget i serien 'Design Patterns Exposed'. I den här serien kommer vi att avslöja varje designmönster från grunden.
Att bara känna till ett programmeringsspråk och dess konstruktioner gör dig inte till en bättre programmerare eller utvecklare. Det kräver kunskap om designmönster för att skapa programvara som fungerar idag och även i framtiden.
Många utvecklare har redan stött på de designproblem som du står inför just nu eller kommer att möta i framtiden. De har angett ett vanligt sätt att hantera det problemet. Så genom att använda designmönster får du fördelen med att använda beprövade tekniker.
Varje designmönster är för att lösa en viss typ av situation. Det kan finnas situationer där mer än ett designmönster kan användas.
De flesta av programmerarna försöker bara lösa problemet de möter utan att bry sig om designmönster, överflödig kod eller till och med tight-coupling. Men bra programmerare börjar annorlunda. De tänker på dagens krav, framtida krav, underhåll av kod och återanvändning av kod.
Bra programmerare har inte bråttom att börja koda när de uppfyller kraven. De sitter och funderar över huruvida deras design kommer att fungera. Om ja, om det fungerar efter 6 månader, när kraven ändras.
Bra programmerare tar sin penna och papper och börjar utforma sina klasser och förhållandet mellan klasserna. De försöker få lös koppling och hög sammanhållning i sin design, medan de gör alla dessa har de objektorienterade principer i åtanke. De går inte in i lågnivåkod omedelbart. För att designa flexibel och återanvändbar programvara bör du följa detta tillvägagångssätt, annars kommer du alltid hitta dig själv att ändra kod som du hade skrivit tidigare.
Det finns bara en sak som är konstant i mjukvaruindustrin och det är Förändra. Kraven kommer säkert att fortsätta att förändras. Så hur utformar vi programvaran som din kod enkelt kan anpassas till framtida krav? För det måste du börja tidigt och utforma det på ett sådant sätt att framtida krav inte bryter mot din tidigare kod.
Hur kan jag göra det?
Tja, det kan göras genom att följa designprinciper och designmönster baserat på dessa principer.
Låt oss nu dyka in i kodning och börja på resan för att bli en bättre programmerare. I det här inlägget kommer vi att avslöja ett av de viktigaste mönstren - Strategimönster .
När jag säger det viktigaste återspeglar det det vanliga problemet som löses genom strategimönster.
Vad är strategimönster?
Här är definitionen direkt från ”Gang of Four” -boken: “Strategimönstret används för att skapa en utbytbar familj av algoritmer där den önskade processen väljs vid körning”.
Om du är detinte kan förstå, oroa dig inte, vi kommer att förklara det i enenklaresättför dig ocksåförstå.
Låt oss först förstå problemet och sedan kommer vi att se hur Strategimönster kan lösa det.
I ovanstående UML-diagram har vi djurabstraktklass och två konkreta klasser, hund och fågel, som sträcker sig från djurets superklass.
Så låt oss definiera en djurabstraktklass och två konkreta klasser, hund och fågel.
Vad tycker du om ovanstående design? Det finns ett stort misstag i vår design.
vad är eko i php
Alla djur kan inte flyga, som i ovanstående fall kan en hund inte flyga. Men ändå har det 'fly' beteende.
Vi gjorde ett misstag genom att skriva den abstrakta fly () -metoden i djurklassen. Denna design tvingar varje underklass hund, fågel, pingvin, krokodil, gås etc. att implementera fly () -metoden.
Vi borde ha förstått att flygning är en förmåga som inte alla djur kommer att ha. Genom att tillhandahålla fly () -metoden i djurabstraktklassen har vi ställt in flygförmågan i alla underklasser som inte är korrekt för alla underklasser av djur.
Du kanske tänker vad som är problemet med att implementera flygmetoden i underklasserna. Även om du kan implementera fly () -metoden i underklasserna för icke-flygande djur för att bara skriva ut 'Jag kan inte flyga'. Men problemet är att du fortfarande ger flugbeteendet till icke-flygande djur. Detta är inte korrekt.
Hur känns det att kalla dog.fly () eller crocodile.fly ().
Så nu har vi förstått att vår design inte är korrekt och vi bör ta bort fly () -metoden från underklassen Animal.
Vad är det andra sättet att utforma våra klasser på ett sätt som vår design inte tvingar alla underklasser till djur att ha flugbeteende.
En lösning som omedelbart kommer att tänka på är att vi kan skapa ett flyggränssnitt med flygmetod och endast djur som kan flyga implementerar det flyggränssnittet. På det här sättet kommer vi inte att genomdriva alla djurunderklasser för att definiera ett flugbeteende. Så låt oss koda denna designmetod.
Nu kommer vår djurklass att se ut som nedanstående kod efter att vi tagit bort flugmetoden från djurklassen.
Låt oss nu definiera det flygande gränssnittet
Nu kommer hundklassen att ändrassomkoden nedan och den behöver inte ha flugbeteende.
Låt oss se några av våra djurunderklasser som kommer att ha flygbeteende.
Vi har löst vårt tidigare problem, men vi kom in i ett nytt problem och det är 'Code Duplication'.
Säg, vi kommer att ha 100 olika underklasser för flygande djur. Vi måste duplicera koden för flygbeteende eftersom flyggränssnittet inte kan ge någon implementering för flygbeteende, och om vi senare vill ändra fly () -metodimplementeringen i någon underklass måste vi öppna den klassen och ändra koden, vilket är dåligt. Vi saknar något stort och det vill säga vi kan inte ändra klassens flygbeteende vid körning.
java scanner få nästa char
Men oroa dig inte, Strategimönster finns för att få dig ur det här problemet.
Så låt oss omformulera vår kod för att använda Strategimönster.
Flygande gränssnitt förblir detsamma som det är. Nu, snarare än att varje flygande underklass implementerar själva flyggränssnittet, kommer vi att definiera separata konkreta klasser som kommer att implementera olika flygbeteenden. Låt oss se hur man gör det.
Så hur allt fungerar, låt oss se TestClass
Genom att använda strategimönster kan vi nu ändra vilket djurs flygbeteende som helst under körning och det är utan att tvinga fram några underklasser för att specificera själva flygbeteendet.
När ska man använda strategimönster?
När du vill kunna ändra beteendet vid körning dynamiskt.
För att se till att du tydligt förstår strategimönstret, låt oss ta ett annat exempel.
I ovanstående anställda klassar vi lönen för den anställde beroende på hans / hennes beteckning. Om en anställd är en 'praktikant' lägger vi till 10% bonus i grundlönen för att beräkna den faktiska lönen.
Om en anställd är en 'webbutvecklare' lägger vi till 20% bonus i grundlönen för att beräkna den faktiska lönen och liknande process följer för andra typer av anställda. Även om vår algoritm för att beräkna den faktiska lönen är väldigt enkel för att göra det lättare att förstå men för det mesta innehåller den många jämförelser och beräkningar.
Så, vad är fel med anställdklasskoden?
Tja, koden för att beräkna lön (getPay ()) är statisk. Antag att jag vill ändra bonusen för 'Intern' från 10% till 14%. Jag måste öppna koden för anställda och ändra den.
Och ett annat problem är att jag inte kan ändra en anställds lönealgoritm vid körning. Så hur gör man det? Strategimönster används specifikt för att hantera denna typ av problem.
Låt oss omformulera koden för att använda strategimönster.
Jag ska definiera flera algoritmer för att beräkna lön. Då kan jag använda någon av dessa algoritmer för att beräkna lön vid körning.
Låt oss nu se hur arbetstagarklassen kommer att förändras.
hur man installerar php windows 10
Notera: Jag har tagit bort löneberäkningslogiken från anställdklassen och skapat en uppsättning PayAlgorithm () -metod genom vilken jag ställer in den PayAlgorithm som jag vill använda för löneberäkning.
Detta ger mig flexibiliteten att beräkna lönen genom att ange vilken PayAlgorithm som helst dynamiskt vid körning. Observera också att jag senare kan skapa en ny PayAlgorithm om jag måste ändra logiken för löneberäkning och använda den för att beräkna lönen. Jag behöver inte ändra den tidigare koden, är det inte bra?
Så låt oss se att det fungerar.
Jag hoppas att du förstod strategimönstret mycket bra. Det bästa sättet att lära sig något är att träna.
Om du har några frågor som rör strategimönster eller något annat mönster, lämna dina frågor nedan.
Se upp för nästa inlägg, där vi kommer att avslöja ett av de mest populära designmönstren, Factory Pattern.
Fram till dess kan du ladda ner kodspelet med det och se till att du cementerar strategimönstret i ditt huvud.
Har du en fråga till oss? Nämn dem i kommentarfältet så återkommer vi till dig.
Relaterade inlägg: