Designmönster är olika lösningar på programvarutekniska problem. Programvaror kan byggas utan dem, men det är mycket svårare.
Jag kommer att släppa en serie i tre delar om designmönster. I det här inlägget kommer jag att diskutera om Creational design patterns.
Creational design patterns är designmönster som handlar om mekanismer för skapande av objekt, där man försöker skapa objekt på ett sätt som passar situationen. Den grundläggande formen för skapande av objekt kan resultera i designproblem eller i ökad komplexitet i designen. Kreativa designmönster löser detta problem genom att på något sätt kontrollera detta objektskapande.
Källa: wikipedia.org
Här ska vi diskutera de fem kreativa designmönstren och hur vi kan använda dem i swift.
Den här typen av designmönster används för att instansiera ett nytt objekt genom att klona ett befintligt objekt som kallas prototyp.
Du skulle se en abstrakt klonfunktion av Fruit-protokollet som implementeras av Apple-klassen och som faktiskt returnerar själva det aktuella objektet.
Låt oss köra ovanstående kod i lekplatsen.
// Create a prototype
let prototype = Apple(count: 4)// Create a copy of existing object
let redApple: Apple = prototype.clone() as! Apple
redApple.count // 4// add own properties
redApple.set(price: "")
redApple.price // // Create a copy of existing object
let greenApple: Apple = prototype.clone() as! Apple
greenApple.count // 4// add own properties
greenApple.set(price: "")
greenApple.price //
– När du klonar ett objekt kopieras alla egenskaper hos det objektet till
ett annat objekt.
– Det här designmönstret bör användas när du behöver skapa ett objekt utan att känna till hierarkin i den klassen
Mönstret med fabriksmetoden
Det är det mest använda designmönstret. I princip abstraherar det bara skapandet av ett objekt.
Skapa en klass som heter FruitFactory som returnerar typen av det objekt som behövs.
Lägg till en statisk metod som accepterar ett enum som heter FruitType som parameter och returnerar det objekt som behövs vid körning.
Alla instanser som returneras av fabriken skulle vara av typen Interface(i swift-protokollet) som alla fabrikskandidatklasser måste ha implementerat.
Efter att ha kört ovanstående kod på lekplatsen:
// get the object of class Orange from the FruitFactory class
let orange = FruitFactory.getFruit(forType: .orange)
orange?.getPrice() // "
orange?.getCount() // 2// get the object of class Grapes from the FruitFactory class
let grapes = FruitFactory.getFruit(forType: .grapes)
grapes?.getPrice() // ""
grapes?.getCount() // 1
– Typen av det skapade objektet bestäms vid körning.
– Detta designmönster gör kodbasen mer flexibel för att lägga till eller ta bort nya typer.
Detta introducerar oss till begreppet program till ett gränssnitt, inte till en implementering.
Detta designmönster tillhandahåller ett gränssnitt för att skapa familjer av relaterade objekt utan att ange deras konkreta klasser. De implementeras ofta med Factory Method-mönstret.
Vi har en abstrakt fabrik som heter Furniture Factory för att skapa olika produkter. Den konkreta fabriksklassen Factory kommer att implementera protokollet Furniture Factory.
Körning av ovanstående kod.
// create MyChair class object
let chair = Factory.createChair()
chair.count() // 4// create MyTable class object
let table = Factory.createTable()
table.count() // 1
– Avslöjar gränssnittet, inte dess implementering
– Abstrakt fabrik är som ett protokoll som vi kommer att använda på en konkret klass för att skapa objekt
Byggarmönster
Detta designmönster separerar processen för skapande av objekt från dess faktiska användning.
Först deklarerar vi ett abstrakt protokoll (eller gränssnitt) för att skapa produkten. I det här fallet är det ShoeShop-protokollet.
Class Nike är en konkret byggare som kapslar in processen för att skapa produkten.
Direktören skapar objektet med hjälp av byggarprotokollet. Director bör initialiseras med objekt som överensstämmer med ShoeShop-protokollet.
Efter att ha kört koden.
// create a nike object
let nike = Nike()// instantiate Director with nike object
let director = Director(shoeShop: nike)// encapsulated the process of producing the nike product
director.produce() // "Shoe produced"
– Använd Builder-mönstret när du bygger offentliga API:er eftersom det inte avslöjar implementeringsdetaljerna
– Döljer komplexiteten. Det ger ett enkelt API bakom en komplex uppgift.
Singleton Design Pattern
I swift definierar vi singletonklasser genom att använda nyckelordet static. Det innebär att objektet endast kommer att instansieras en gång. Statiska egenskaper är lata initialiserade och kommer inte att instansieras förrän de anropas.
Det finns bara en kopia av det här objektet och används av de andra objekten globalt.
Vi kan se användningen även i Apples ramverk:
// Shared url session
let urlSession = URLSession.shared// user defaults
let userDefaults = UserDefaults.standard
Efter att ha kört koden
Vehicle.sharedInstance.getName() // "Car"
– Vi använder nyckelordet let för att försäkra oss om att shredInstance’s värde inte kommer att förändras
– Glöm inte att lägga till private initializer för att hindra andra klasser från att anropa dess standardinitialiserare
Här är länken till lekmiljöfilerna.
Den främsta anledningen till att vi använder Creational Design Pattern är att frikoppla logiken för skapandet av ett objekt från dess användning. Det hjälper till att minska komplexiteten genom att skapa objekt på ett kontrollerat sätt med redan nämnda beprövade & testade lösningar.
För att läsa om beteendemässiga designmönster, här är länken till bloggen.