Written by Reinder de Vries on January 10 2019 In App Development, Swift

singleton on luokka, jonka täsmälleen yksi esiintymä on olemassa, että voidaan maailmanlaajuisesti. Miten Swiftissä luodaan singleton? Miksi sinun pitäisi tai ei pitäisi?

tässä opetusohjelmassa sukelletaan Swiftin singletoneihin. Opit, mitä singleton design malli on, ja miksi se on hyödyllinen. Keskustelemme Swiftin singletonien syntaksista. Ja päädymme hyviin ja huonoihin käyttöjuttuihin singletoneille.

valmis? Mennään.

  1. Mikä On Singleton?
  2. Singletonin Koodaaminen Swiftissä
  3. Milloin Käyttää Singletoneja
  4. Jatkolukemista

Mikä On Singleton?

singleton on luokka, josta on olemassa vain yksi esiintymä. Muutama esimerkki:

  • yhtiöllä on vain yksi CEO
  • API-luokalla on vain yksi sarjapyyntöjono
  • käyttöjärjestelmällä on vain yksi tiedostojärjestelmä
  • aurinkokunnan kappale pyörii yhden gravitaatiopisteen ympärillä
  • sovellus jolla I/O on vain yksi oletus FileManager
  • lentokoneessa on vain yksi lentokansi

Singletonin toinen ominaisuus on, että sillä on maailmanlaajuinen KULKUPISTE. Voit käyttää singleton, esim. soita toimintoja sitä, mistä tahansa sovelluksen koodi.

niin, yhteenvetona:

  1. singleton on luokka, jolla on vain yksi esiintymä
  2. sitä voi käyttää maailmanlaajuisesti, eli missä tahansa omassa koodissa

käytännön iOS-kehityksessä käytetään singletoneja usein. Tyypillisiä luokkia kuten NotificationCenter, UserDefaults, SKPaymentQueue ja FileManager on shared tai default ominaisuuksia, jotka ovat singlettejä.

muina aikoina voi haluta luoda Singletonin itse. Hyvä käyttötapaus on API – luokka, joka altistaa singleton-instanssin shared – ominaisuutensa kautta. Voit käyttää API.shared.makeAPICall() API: a yhden, yhtenäisen instanssin kautta. Näin voit esimerkiksi hallita API-puheluita sarjallisesti.

ennen kuin keskustellaan siitä, milloin singletoneja parhaiten käytetään (ja milloin ei), selvitetään, miten Swiftissä singletonia koodataan.

Hanki työpaikka iOS-kehittäjänä

Opi rakentamaan iOS 14-sovelluksia Swift 5: llä

Rekisteröidy iOS development course-kurssille ja opi aloittamaan urasi ammattimaisena iOS-kehittäjänä.

koodaus Singleton Swiftissä

tämä on paras tapa luoda singleton Swiftissä:

class API{ static let shared = API() private init() { // Set up API instance }}

ja näin käytät singletonia:

API.shared.doSomething()

luomme API – luokan, jolla on yksi staattinen ominaisuus nimeltä shared. Tätä ominaisuutta ei voi muuttaa kerran asetettuna, koska se on vakio, ja se julistetaan staattisesti.

se tarkoittaa, että pääsemme shared kiinteistöön luokan APIkautta. Tätä kutsutaan usein luokan omaisuudeksi. Vertaa tätä normaaliin instanssiominaisuuteen, johon pääsee vain luokan instanssin kautta.

mielenkiintoista on, että shared ominaisuus alustaa API: n esiintymän API luokan sisällä. Olemme tavallaan luomassa API – objektia, johon pääsee API – luokan kautta. Mutta on muutakin…

luokan alustaja init() merkitään private. Tällä private avainsanalla varmistetaan, että API – luokka voidaan alustaa vain API – luokan sisällä.

toisin sanoen API: n instanssia ei voi luoda API luokan ulkopuolelle! Näin varmistetaan, että API luomamme objekti on ainoa ilmentymä koodissamme. Loppujen lopuksi sitä ei voi luoda lisää.

Ja nyt on varmistettu, että API luokka vastaa Singletonin kahta ominaisuutta:

  1. staattisen ominaisuuden shared ansiosta API instanssi on saavutettavissa maailmanlaajuisesti
  2. private init() ansiosta API luokkaa ei voi alustaa API luokan

ulkopuolella tämä kaikki saattaa kuulostaa sinusta hieman abstraktilta, joten laajennetaan edellistä esimerkkiä hieman käytännöllisemmällä koodilla. Tässä mitä:

API luokka on pääosin sama. Se on edelleen singleton, ja se käyttää edelleen niitä static let shared = API() ja private init() koodinpätkiä.

Here ’s what’ s changed:

  • API luokalla on nykyään isRequestPending kiinteistö. Tästä vaara alkaa … Näetkö kuinka isRequestPending boolean varmistaa, että vain yksi API-pyyntö voidaan tehdä kerrallaan? (Huomaa, että isRequestPending on instanssin ominaisuus.)
  • API luokalla on myös makeAPIRequest() funktio. Kuvittele, että voimme käyttää tätä toimintoa saadaksemme tietoja takaisin webservice API: sta, kuten Twitteristä. toiminnosta näet, että pyyntö voidaan tehdä vain silloin, kun mikään muu pyyntö ei ole vireillä.
  • API luokalla on myös onReturnAPIRequest() funktio. Tähän funktioon vedotaan, kun API-pyyntö palaa eli sovellukseen on ladattu Online-dataa. isRequestPending boolean asetetaan jälleen arvoon false, ja pyyntötiedot käsitellään.

ja näin voimme käyttää API singletonia missä tahansa koodissamme:

API.shared.makeAPIRequest()

meidän pitää puhua eräästä muusta. API – luokka hallitsee nyt jotain niin sanottua valtiota. Voit nähdä ”valtion” tunteena: olet joko onnellinen tai surullinen tai vihainen ja niin edelleen. Voit vaihtaa osavaltiosta toiseen.

API luokka voi vaihtaa kahden valtion välillä:

  • valtio, jossa isRequestPending on false
  • valtio, jossa isRequestPending on true

kuten seuraavasta osiosta selviää, valtio ja singletonit voivat aiheuttaa kaikenlaisia tuhoja koodillesi. Valtion huono johtaminen on suurin yksittäinen syy Singletonin väärinkäytöksiin.

milloin käytät Singletoneja

milloin käytät singletoneja? Neljän koplan kirja Design Patterns: Elements Of Reusable Object-Oriented Software kertoo seuraavaa. Käytä singleton kuvio, kun:

  • on oltava täsmälleen yksi luokan instanssi, ja sen on oltava asiakkaiden saatavilla tunnetusta tukiasemasta
  • , kun ainoa instanssi olisi laajennettava alaluokalla, ja asiakkaiden olisi voitava käyttää laajennettua instanssia muuttamatta koodiaan

se on monimutkainen, mutta mitä se pohjimmiltaan on:

  • käytä singletonia, kun koodisi vaatii enintään yhden luokan ilmentymän (eli yrityksen toimitusjohtajan)
  • ja kun sen on oltava saatavilla mistä tahansa koodisi kohdasta (ts., tiedostojärjestelmä)

toinen käyttötapaus on aliluokitus. Koodisi globaalia muuttujaa ei voi helposti alittaa, joten siksi käytät singleton-luokkaa. Lisäksi singletonit voidaan yksikkötestata riippuvuusinjektiolla. Korvaat API – instanssin APIMock – instanssilla ja saat mahdollisuuden yksikkökohtaisiin TESTIRAJAPINTAPUHELUIHIN tekemättä varsinaisia verkkopyyntöjä.

ja milloin et käytä singletoneja? Vastataksemme kysymykseen meidän on palattava valtioperiaatteeseen, josta keskustelimme aiemmin.

yleinen sudenkuoppa aloitteleville iOS-kehittäjille on hallita tilaa ja sen riippuvuuksia huonosti. Kuvittele rakentavasi sovellusta, joka käyttää aiemmin tekemäämme API – luokkaa.

joka kerta kun laajennat API-luokkaa, käytät yhä enemmän ominaisuuksia, kuten:

  • a userID ominaisuus, joka pitää kirjaa kirjautuneesta käyttäjästä, kun login() API-puhelu on tehty
  • a tweets Twitter-tiedoilla varustettu ominaisuus, kun getTweets() puhelu on tehty
  • a spinner ominaisuus, jossa on UIActivityIndicatorView, jonka lisäät näkymäohjaimeen, kun pyyntö on alkanut

aluksi tässä on paljon järkeä. Loppujen lopuksi API – luokkaan pääsee käsiksi missä tahansa omassa tunnuksessa. Tweet View Controllerissa voit siis käyttää API.shared.tweets array-toimintoa, ja Asetusohjaimessa voit käyttää userID – toimintoa kertoaksesi nopeasti API: n, jonka asetuksia pitää muuttaa.

valitettavasti valtiosi on nyt kaikkialla. API – luokalla on riippuvuuksia joukosta luokkia, jotka eivät liity API-luokan yksittäiseen vastuuseen. Koodistasi on tullut spagettikulho. Koodi voi toimia hyvin, mutta sitä on mahdotonta ylläpitää ja laajentaa.

Katsotaanpa esimerkkiä. Aiemmin määrittelemämme onReturnAPIRequest() funktio on tulossa tiukkaan kytkettäväksi …

tässä on mitä harkitsemme:

  • onReturnAPIRequest() kutsutaan kun API webservice-pyyntö palaa, eli kun tieto tulee sovellukseen. Nämä tiedot täytyy mennä jonnekin-Tweet View Controller esimerkiksi. Miten API: n tiedot välitetään näkymäohjaimelle?
  • ilmeinen valinta on vain luoda viittaus viewController API luokkaan. Kun tieto tulee, voi koodata jotain viewController.tweets = tweetsData. Tämä on valitettavasti huonoa arkkitehtuuria, sillä nyt API ja näkymäohjain ovat tiukasti kytköksissä toisiinsa. Se on mahdotonta (tai vaikea) Yksikkö Testi, ja todennäköisesti aiheuttaa ongelmia, kun laajennetaan jompaakumpaa luokkaa.
  • on parempi valita mekanismi, joka ei tiukasti yhdistä molempia luokkia. Yksi vaihtoehto olisi siirtää sulkeminen tasolle onReturnAPIRequest(), joka suoritetaan, kun pyyntö palaa. Tämä sulkeminen voi sitten sisältää koodia saapuvien tietojen käsittelemiseksi. Toinen vaihtoehto olisi käyttää NotificationCenter – luokkaa tietojen välittämiseen katseluohjaimelle tai käyttää Database – luokkaa tietojen käsittelyyn.

Singletonin suunnittelukuvio on herättänyt jonkin verran kiistaa jo pelkästään siksi, että sitä on helppo käyttää väärin. Kun käytät singletoneja, ota huomioon tila ja riippuvuudet. Vaikka osavaltioon on helppo päästä globaalisti, se ei tarkoita, että se olisi hyvä idea.

Hanki työpaikka iOS-kehittäjänä

Opi rakentamaan iOS 14-sovelluksia Swift 5: llä

Rekisteröidy iOS development course-kurssille ja opi aloittamaan urasi ammattimaisena iOS-kehittäjänä.

Lisää lukemista

ja siinä kaikki! Singletoneihin tutustuminen kannattaa, varsinkin jos sovellusarkkitehtuuri ja järjestelmäsuunnittelu kiinnostavat.

Vastaa

Sähköpostiosoitettasi ei julkaista.