Designmønstre er forskellige løsninger på softwareudviklingsproblemer. Softwares kan bygges uden dem, men det er meget sværere.
Jeg vil udgive en serie i tre dele vedrørende designmønstre. I dette indlæg vil jeg diskutere om Creational designmønstre.

Creational designmønstre er designmønstre, der beskæftiger sig med objektoprettelsesmekanismer, hvor man forsøger at skabe objekter på en måde, der passer til situationen. Den grundlæggende form for objektoprettelse kan resultere i designproblemer eller i ekstra kompleksitet til designet. Kreative designmønstre løser dette problem ved på en eller anden måde at kontrollere denne objektoprettelse.
Kilde: wikipedia.org

Her skal vi diskutere de fem kreative designmønstre, og hvordan vi kan bruge dem i swift.

Denne type designmønster bruges til at instantiere et nyt objekt ved at klone et eksisterende objekt kaldet prototype.

Du ville se en abstrakt klonfunktion af Fruit-protokollen, der er implementeret af Apple-klassen, som faktisk returnerer selve det aktuelle objekt.

Lad os køre ovenstående kode i legepladsen.

// 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 kloner et objekt, kopieres alle egenskaberne ved det pågældende objekt til
et andet objekt.
– Dette designmønster bør bruges, når du skal oprette et objekt uden at kende hierarkiet i den pågældende klasse

Factory Method Pattern

Det er det mest almindeligt anvendte designmønster. Grundlæggende abstraherer det blot oprettelsen af et objekt.

Opret en klasse kaldet FruitFactory, der returnerer typen af det nødvendige objekt.
Føj en statisk metode til, der accepterer et enum kaldet FruitType som parameter og returnerer det nødvendige objekt ved kørselstid.

Alle instanser, der returneres af fabrikken, vil være af typen Interface(i swift-protokollen), som alle fabrikkens kandidatklasser skal have implementeret.

Når ovenstående kode køres på legepladsen:

// 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 af det oprettede objekt bestemmes ved kørselstid.
– Dette designmønster gør kodebasen mere fleksibel til at tilføje eller fjerne nye typer.

Dette introducerer os til begrebet program til en grænseflade, ikke en implementering.

Dette designmønster giver en grænseflade til at skabe familier af relaterede objekter uden at angive deres konkrete klasser. De implementeres ofte med Factory Method-mønsteret.

Vi har en abstrakt fabrik kaldet Furniture Factory til at skabe forskellige produkter. Den konkrete fabriksklasse Factory vil implementere Furniture Factory-protokollen.

Kørsel af ovenstående kode.

// create MyChair class object
let chair = Factory.createChair()
chair.count() // 4// create MyTable class object
let table = Factory.createTable()
table.count() // 1

– Afslører grænsefladen, ikke deres implementering
– Abstrakt Factory er som en protokol, som vi vil bruge på en konkret klasse til at oprette objekter

Builder Pattern

Dette designmønster adskiller processen for oprettelse af objekter fra dens faktiske brug.

Først erklærer vi en abstrakt protokol(eller grænseflade) til at oprette produktet. I dette tilfælde er det ShoeShop-protokollen.
Class Nike er en konkret builder til indkapsling af produktskabelsesprocessen.

Director opretter objektet ved hjælp af builder-protokollen. Director skal initialiseres med objekt, der er i overensstemmelse med ShoeShop-protokollen.

Når koden køres.

– Brug Builder-mønsteret, når du bygger offentlige API’er, fordi det ikke afslører implementeringsdetaljerne
– Skjuler kompleksiteten. Det giver et simpelt API bag en kompleks opgave.

Singleton-designmønster

I swift definerer vi Singleton-klasser ved at bruge nøgleordet static. Det betyder, at objektet kun vil blive instantieret én gang. Statiske egenskaber er dovent initialiserede og vil ikke blive instantieret, før de kaldes.
Der er kun én kopi af dette objekt, og det bruges af de andre objekter globalt.

Vi kan også se brugen i Apple-rammer:

// Shared url session
let urlSession = URLSession.shared// user defaults
let userDefaults = UserDefaults.standard

Når koden er kørt

Vehicle.sharedInstance.getName() // "Car"

– Vi bruger nøgleordet let for at sikre, at shredInstance’s værdi ikke ændres
– Glem ikke at tilføje den private initialisator for at forhindre andre klasser i at kalde dens standardinitialisatorer

Her er linket til legepladsfilerne.

Den vigtigste grund til, at vi bruger Creational Design Pattern, er at afkoble logikken i forbindelse med oprettelsen af et objekt fra dets brug. Det hjælper med at reducere kompleksiteten ved at skabe objekter på en kontrolleret måde med allerede nævnte afprøvede & testede løsninger.

For at læse om adfærdsmæssige designmønstre, er her linket til bloggen.