de Navdeep Singh

Să examinăm avantajele și dezavantajele modelului de design Singleton

Sa examinam avantajele si dezavantajele modelului de design Singleton

Modelele de proiectare sunt instrumente conceptuale pentru rezolvarea problemelor software complexe. Aceste tipare sunt soluții simple și elegante, care au evoluat de-a lungul timpului și pot fi acceptate în general ca fiind cea mai bună modalitate de a aborda anumite provocări de proiectare. – Eu, în cartea mea electronică Programare reactivă cu Swift 4

Model de proiectare Singleton

Modelul Singleton încapsulează o resursă partajată într-o singură instanță de clasă unică. Această instanță arbitrează accesul la informațiile de stare legate de resurse și stocare. O metodă de clasă oferă referința la această instanță, deci nu este nevoie să treceți referința. Orice obiect care are acces la antetul clasei Singleton poate folosi Singleton.

Acest model de proiectare definește structura unei clase care poate avea o singură instanță. Un Singleton încapsulează o resursă unică și o face ușor disponibilă în întreaga aplicație. Resursa poate fi hardware, un serviciu de rețea, un magazin persistent sau orice altceva care poate fi modelat ca un obiect sau serviciu unic.

Un exemplu din Cocoa touch este un dispozitiv fizic care rulează o aplicație iOS. Pentru o aplicație în execuție, există un singur iPhone sau iPad cu o singură baterie și un ecran. UIDevice este o clasă Singleton aici, deoarece oferă un canal pentru a interacționa cu caracteristicile subiacente. În cazul în care resursa unică are o configurație scrisă, acest tip de discrepanță poate duce la probleme precum starea cursei și impasul. Deoarece sunt unice, Singletonii acționează ca un control, asigurând accesul ordonat la resursa partajată.

Singletonii pot fi adesea modelați ca un server în cadrul aplicației care acceptă cererile de trimitere, stocare sau recuperare a datelor și configurarea stării resurselor.

Implementare

Implementarea modelului Singleton creează adesea un singur obiect folosind metoda din fabrică, iar această instanță / obiect este numită instanță partajată în majoritatea cazurilor. Deoarece accesul la instanță este transmis printr-o metodă de clasă, este eliminată necesitatea de a crea un obiect. Să ne uităm la implementarea Singleton în cod.

Pentru acest exemplu, am folosit instrument pentru linia de comandă Șablon Xcode pentru a crea un proiect și a-l denumi Singleton. Se cheamă clasa noastră Singleton SingletonObject, pe care l-am creat ca o clasă normală de cacao și este o subclasă a NSObject. Configurarea proiectului arată astfel până acum:

1611483727 3 Sa examinam avantajele si dezavantajele modelului de design Singleton

Apoi am adăugat o metodă de clasă numită sharedInstance după cum sa discutat mai devreme, deoarece acesta este modul în care clasa va pune la dispoziție Singleton. Valoarea sa de returnare este de SingleObject tastați, după cum urmează:

func sharedInstance() -> SingletonObject {         }

Funcția stochează instanța într-o referință locală statică numită localSharedInstance. Localnicii statici seamănă mult cu obiectele globale – își păstrează valoarea pe durata de viață a aplicației, totuși au un domeniu limitat. Aceste calități le fac ideale pentru a fi un Singleton, deoarece sunt permanente și totuși asigură faptul că Singleton-ul nostru este disponibil numai prin intermediul Instanței partajate.

Acesta este unul dintre modurile în care implementarea noastră Singleton asigură faptul că Singleton rămâne singular. Structura de bază a instanței partajate constă dintr-un bloc condițional care testează dacă a fost alocată o instanță Singleton. Dar, în mod surprinzător, acesta este modul mai vechi de a face lucrurile (sau poate fi calea de urmat în alte limbi). Cu toate acestea, în Swift, implementarea sa schimbat într-o singură linie și nu avem nevoie de o metodă. Implementarea arată astfel:

class SingletonObject: NSObject {    static let sharedInstance = SingletonObject()}

Simplu, nu-i așa?

Model de design Singleton – Pro și contra

Singletonii nu sunt răspunsul la fiecare problemă. La fel ca orice instrument, acestea pot fi reduse sau pot fi suprautilizate.

Unii dezvoltatori critică Singletoni din diverse motive. Vom examina această critică și vom discuta despre modalitățile de abordare a acestora pe scurt. Criticile, în mare parte, se împart în două categorii:

  • Singletonii împiedică testarea unității: Un Singleton ar putea cauza probleme pentru scrierea codului testabil dacă obiectul și metodele asociate acestuia sunt atât de strâns cuplate încât devine imposibil de testat fără a scrie o clasă complet funcțională dedicată Singletonului.
  • Singletonii creează dependențe ascunse: Deoarece Singleton este ușor disponibil în întreaga bază de cod, acesta poate fi folosit în exces. Mai mult, deoarece referința sa nu este complet transparentă în timp ce trece la diferite metode, devine dificil de urmărit.

Pentru a evita aceste complicații, atunci când luați în considerare modelul Singleton, ar trebui să vă asigurați că clasa este un Singleton. De asemenea, în timp ce vă gândiți să proiectați modelul de proiectare Singleton, țineți cont de teste și utilizați injecția de dependență ori de câte ori este posibil – adică încercați să transmiteți Singleton ca parametru inițializatorului ori de câte ori este posibil.

Pentru alte actualizări, mă puteți urmări pe Twitter pe mânerul meu de Twitter @NavRudraSambyal

Pentru a citi mai multe despre diferite alte modele de design și exemple de practică, puteți urmări linkul către cartea mea Programare reactivă în Swift 4

Vă mulțumim pentru lectură, vă rog să-l împărtășiți dacă vi s-a părut util 🙂