Suunnittelumallit ovat erilaisia ratkaisuja ohjelmistotekniikan ongelmiin. Ohjelmistoja voidaan rakentaa ilman niitä, mutta se on paljon vaikeampaa.
Julkaisen kolmiosaisen sarjan koskien suunnittelumalleja. Tässä postauksessa käsittelen luovia suunnittelumalleja.

Luovat suunnittelumallit ovat suunnittelumalleja, jotka käsittelevät objektien luomismekanismeja ja pyrkivät luomaan objekteja tilanteeseen sopivalla tavalla. Objektien luomisen perusmuoto voi johtaa suunnitteluongelmiin tai lisätä monimutkaisuutta suunnitteluun. Luovat suunnittelumallit ratkaisevat tämän ongelman kontrolloimalla jotenkin tätä objektien luomista.
Lähde: wikipedia.org

Tässä keskustelemme viidestä luovasta suunnittelumallista ja siitä, miten voimme käyttää niitä swiftissä.

Tätyyppistä suunnittelumallia käytetään uuden objektin instantiointiin kloonaamalla olemassa oleva objekti, jota kutsutaan prototyypiksi.

Näyttäisi Apple-luokan toteuttaman Fruit-protokollan abstraktin kloonifunktion, joka itse asiassa palauttaa nykyisen objektin itsensä.

Ajetaan yllä oleva koodi leikkikentällä.

// 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 // 

– Kun kloonaat objektin, kaikki objektin ominaisuudet kopioidaan
toiseen objektiin.
– Tätä suunnittelumallia kannattaa käyttää silloin, kun täytyy luoda objekti tuntematta kyseisen luokan hierarkiaa

Tehdasmenetelmämalli

Se on yleisimmin käytetty suunnittelumalli. Periaatteessa se vain abstrahoi objektin luomisen.

Luo luokka nimeltä FruitFactory, joka palauttaa tarvittavan objektin tyypin.
Lisää staattinen metodi, joka hyväksyy parametrina enumin nimeltä FruitType ja palauttaa ajoaikana tarvittavan objektin.

Tehtaan palauttama instanssi olisi tyypiltään Interface (swift-protokollassa), jonka minkä minkä tahansa tehtaan ehdokkaaksi pyrkivän luokan on täytynyt toteuttaa.

Ylläolevan koodin ajamisen jälkeen leikkikentällä:

// 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

– Luodun objektin tyyppi määräytyy ajonaikana.
– Tämä suunnittelumalli tekee koodipohjasta joustavamman uusien tyyppien lisäämiseksi tai poistamiseksi.

Tämä esittelee meille käsitteen ohjelmoida rajapinta rajapintaan, ei toteutukseen.

Tämä suunnittelumalli tarjoaa rajapinnan toisiinsa liittyvien objektien perheiden luontiin määrittelemättä konkreettisia luokkia. Ne toteutetaan usein Factory Method -mallin avulla.

Meillä on abstrakti tehdas nimeltä Furniture Factory erilaisten tuotteiden luomista varten. Konkreettinen tehdasluokka Factory toteuttaa Furniture Factory -protokollan.

Ajetaan yllä oleva koodi.

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

– Paljastaa rajapinnan, ei niiden toteutusta
– Abstrakti Factory on kuin protokolla, jota käytämme konkreettiseen luokkaan objektien luomiseksi

Builder Pattern

Tämä suunnittelumalli erottaa objektien luomisprosessin niiden varsinaisesta käytöstä.

Ensiksi julistamme abstraktin protokollan (tai rajapinnan) tuotteen luomista varten. Tässä tapauksessa se on ShoeShop-protokolla.
Luokka Nike on konkreettinen rakentaja, joka kapseloi tuotteen luomisprosessin.

Ohjaaja luo objektin käyttäen rakentajan protokollaa. Director tulee alustaa ShoeShop-protokollan mukaisella objektilla.

Koodin suorittamisen jälkeen.

// 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"

– Käytä Builder-mallia rakennettaessa julkisia API:ita, koska se ei paljasta toteutuksen yksityiskohtia
– Piilottaa monimutkaisuuden. Se tarjoaa yksinkertaisen API:n monimutkaisen tehtävän taakse.

Singleton Design Pattern

Swiftissä määritellään Singleton-luokat käyttämällä static-avainsanaa. Se tarkoittaa, että objekti instantioidaan vain kerran. Staattiset ominaisuudet alustetaan laiskasti, eikä niitä instantioida ennen kuin niitä kutsutaan.
Tästä objektista on vain yksi kopio ja sitä käyttävät muut objektit globaalisti.

Näemme käytön myös Applen kehyksissä:

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

Koodin suorittamisen jälkeen

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

– Käytämme let-avainsanaa varmistaaksemme, että shredInstance:n arvo ei muutu
– Älä unohda lisätä yksityistä initialisaattoria, jotta muut luokat eivät kutsu sen oletusinitialisaattoreita

Tässä on linkki leikkitiedostoihin.

Pääsyy siihen, että käytämme Creational Design Patternia, on irrottaa objektin luomisen logiikka sen käytöstä. Se auttaa vähentämään monimutkaisuutta luomalla objekteja hallitusti jo mainituilla kokeilluilla & testatuilla ratkaisuilla.

Jos haluat lukea käyttäytymissuunnittelumalleista, tässä on linkki blogiin.