Fabriksmetoden designmönster i Python

introduktion

i den här artikeln kommer vi att dyka in i Fabriksmetoden designmönster, implementerat i Python.

designmönster definierar beprövade lösningar på olika återkommande problem inom mjukvaruutveckling. De representerar inte själva koden, utan snarare sätt på vilka vi kan organisera vår kod för optimala resultat.

i en värld av begränsade resurser hjälper designmönster oss att uppnå flest resultat med minst använda resurser. Det är också viktigt att notera att designmönster inte gäller för alla situationer och det är viktigt att bedöma problemet för att välja den bästa metoden för just det scenariot.

designmönster är indelade i några breda kategorier, men främst i Kreationsmönster, strukturella mönster och beteendemönster.

Fabriksmetoden mönstret är en Creational Design Mönster.

Fabriksmetoden designmönster

Definition

Fabriksmetoden används i objektorienterad programmering som ett sätt att tillhandahålla fabriksgränssnitt för att skapa objekt. Dessa gränssnitt definierar den generiska strukturen, men initierar inte objekt. Initialiseringen lämnas till mer specifika underklasser.

moderklassen / gränssnittet innehåller alla standard-och generiska beteenden som kan delas över underklasser av olika typer. Underklassen är i sin tur ansvarig för definitionen och instansieringen av objektet baserat på superklassen.

Motivation

huvudmotivet bakom Fabriksmetoden designmönster är att förbättra lös koppling i kod genom att skapa en abstrakt klass som kommer att användas för att skapa olika typer av objekt som delar några vanliga attribut och funktionalitet.

detta resulterar i ökad flexibilitet och återanvändning av kod eftersom den delade funktionaliteten inte kommer att skrivas om efter att ha ärvts från samma klass. Detta designmönster är också känt som en virtuell konstruktör.

Fabriksmetoden designmönster används ofta i bibliotek genom att låta kunder välja vilken underklass eller typ av objekt som ska skapas genom en abstrakt klass.

en Fabriksmetod kommer att få information om ett obligatoriskt objekt, instantiera det och returnera objektet av den angivna typen. Detta ger vår applikation eller vårt bibliotek en enda interaktionspunkt med andra program eller kodstycken och därigenom inkapslar vår objektskapande funktionalitet.

Factory method Implementation

vårt program kommer att bli ett bibliotek som används för att hantera formobjekt när det gäller skapande och andra operationer som att lägga till färg och beräkna formens yta.

användare ska kunna använda vårt bibliotek för att skapa nya objekt. Vi kan börja med att skapa enskilda enskilda former och utnyttja dem som de är men det skulle innebära att mycket delad logik måste skrivas om för varje form vi har tillgängliga.

det första steget för att lösa denna upprepning skulle vara att skapa en överordnad formklass som har metoder som calculate_area() och calculate_perimeter() och egenskaper som dimensioner.

de specifika formobjekten kommer sedan att ärva från vår basklass. För att skapa en form måste vi identifiera vilken typ av form som krävs och skapa underklassen för den.

vi börjar med att skapa en abstrakt klass för att representera en generisk form:

detta är basklassen för alla våra former. Låt oss gå vidare och skapa flera konkreta, mer specifika former:

hittills har vi skapat en abstrakt klass och utökat den för att passa olika former som kommer att finnas tillgängliga i vårt bibliotek. För att skapa de olika formobjekten måste kunderna känna till namnen och detaljerna i våra former och utföra skapandet separat.

det är här Fabriksmetoden spelar in.

Fabriksmetoden designmönster hjälper oss att abstrahera Tillgängliga Former från klienten, dvs klienten behöver inte känna till alla tillgängliga former, utan skapar bara vad de behöver under körning. Det kommer också att tillåta oss att centralisera och inkapsla objektskapandet.

Låt oss uppnå detta genom att skapa en ShapeFactory som kommer att användas för att skapa specifika formklasser baserat på klientens inmatning:

Detta är vårt gränssnitt för skapande. Vi kallar inte konstruktörerna av betongklasser, vi kallar fabriken och ber den att skapa en form.

vår ShapeFactory fungerar genom att ta emot information om en form som ett namn och de nödvändiga dimensionerna. Vår fabriksmetod create_shape() kommer sedan att användas för att skapa och returnera färdiga objekt av önskade former.

klienten behöver inte veta något om objektets skapande eller detaljer. Med hjälp av fabriksobjektet kan de skapa objekt med minimal kunskap om hur de fungerar:

att köra den här koden kommer att resultera i:

eller vi kan bygga en annan form:

vad som är värt att notera är att förutom att klienten inte behöver veta mycket om skapandeprocessen – när vi vill instansiera ett objekt kallar vi inte klassens konstruktör. Vi ber fabriken att göra detta för oss baserat på den information vi skickar till funktionen create_shape().

fördelar och nackdelar

fördelar

en av de stora fördelarna med att använda Fabriksmetoden designmönster är att vår kod blir löst kopplad genom att majoriteten av komponenterna i vår kod inte känner till andra komponenter i samma kodbas.

detta resulterar i kod som är lätt att förstå och testa och lägga till mer funktionalitet till specifika komponenter utan att påverka eller bryta hela programmet.

Fabriksmetoden designmönster hjälper också till att upprätthålla principen om enskilt ansvar där klasser och objekt som hanterar specifik funktionalitet resulterar i bättre kod.

nackdelar

skapande av fler klasser leder så småningom till mindre läsbarhet. Om den kombineras med en abstrakt fabrik (fabrik av fabriker), kommer koden snart att bli verbose, men underhållbar.

slutsats

Sammanfattningsvis tillåter Fabriksmetoden designmönster oss att skapa objekt utan att ange den exakta klassen som krävs för att skapa det specifika objektet. Detta gör att vi kan koppla bort vår kod och förbättra dess återanvändbarhet.

det är viktigt att notera att det, precis som alla andra designmönster, endast är lämpligt för specifika situationer och inte alla utvecklingsscenarier. En bedömning av den aktuella situationen är avgörande innan man beslutar att implementera Fabriksmetoden designmönster för att skörda fördelarna med mönstret.

Lämna ett svar

Din e-postadress kommer inte publiceras.