Introduktion till programmering, del 14 – Designmönster

På torsdag äts det ärtsoppa, på fredag är det fest, men onsdag är ändå den dagen som känns bäst! 😀

Introduktion till programmering

Förra veckan gick vi kort igenom optimering och vilken effekt det kan ha på slutprodukten. Idag ska vi kort gå igenom vad ”Designmönster” är och vad de är bra för!

I programmering, precis som inom många andra fält, finns återkommande problem som smidigast löses på ungefär samma sätt. Man började därför att hitta på ”designmönster”, vilket är mönster att arbeta efter för att lösa olika programmeringsproblem (främst inom objektorientering).
Förra gången nämnde jag ”The Blob”, vilket är ett ”anti-designmönster”. Detta innebär att det är ett designmönster som försvårar snarare än förenklar eftersom det går ut på att man lägger på tok för mycket funktionalitet i samma klass.
I exemplet som då togs upp, kunde man löst problemet med designmönstret ”komponenthanterare”. Genom att definiera ett antal komponenter och sedan implementera precis de man vill ha i varje givet objekt, minimerar man risken för buggar som är svåra att hitta senare.
Så har du ett svårlöst problem med koduppbyggnad, är det troligt att någon redan haft samma problem och skapat en mall för hur man kan göra för att lösa det.
Här är några exempel på designmönster som är bra att känna till:

Factory

Ett Factory-objekt returnerar färdiga objekt av någon viss typ, ofta olika. Exempelvis kan man ha en factory som returnerar objekten ”Boll” eller ”Cykel” baserat på anrop.

Builder

Buildern påminner om Factory, fast skillnaden är att man instruerar Buildern med hur man vill att objektet ska se ut och kan sedan hämta ut det från Buildern när det är färdigställt. Ett exempel är om man bygger ett Hus-objekt, och först instruerar Buildern hur huset ska vara uppbyggt innan man hämtar objektet.

Composite

Ett komposit-objekt består av endast ett objekt, eller så länkar det också till en lista med fler instanser av samma objekt. Detta är en lite avancerad typ av datatyp som vi kan tänkas komma tillbaka till senare.

Adapter

Om man har två snarlika objekt, men vars metoder skiljer sig åt, men vill kunna anropa dessa på samma sätt, kan man använda en adapter. Adaptern blir som ett ”omslutande objekt”, som tar ett anrop och omvandlar det till ett anrop som det omslutna objektet kan tolka.
Den uppmärksamme har tidigare noterat våra guider där vi styr ett robotkit med Raspberry Pi och RaspiRobotBoard V2 eller L298. Kodanropen för att använda dessa ser normalt sett olika ut, men med adaptermönstret kan vi skapa anrop för L298 som ser likadana ut som för RRBv2. Detta genom att skapa en omslutande klass för L298-anropen vars metoder ser likadana ut som de i RRBv2-biblioteket, men som i sin tur bara skickar vidare anropen korrekt till L298.

Detta var mest tänkt som en kort introduktion till designmönster, för att informera om vad det är. Jag tänker inte gå in djupare på ämnet i nuläget eftersom det finns roligare saker att lära sig.
Om du känner att detta var väldigt intressant och vill lära dig mer kan jag rekommendera boken ”Design Patterns” av ”Gang of four” (de fyra författare som skrev boken tillsammans).
Det var allt för denna gång, nästa vecka ska vi gå igenom hur grafiska interface fungerar och hur man kan skapa några enkla sådana!

Kommentera