Singleton Pattern, iespējams, ir visplašāk izmantotais dizaina modelis. Tas ir vienkāršs modelis, viegli saprotams un lietojams. Dažreiz to izmanto pārmērīgi un gadījumos, kad tas nav nepieciešams. Šādos gadījumos lietošanas trūkumi ir lielāki par tā sniegtajām priekšrocībām. Šī iemesla dēļ viengabala modelis dažreiz tiek uzskatīts par antiraksts vai raksta vienkrāsains .

Svarīgas tēmas Singleton metodes dizaina modelim

• Kas ir Singleton metodes dizaina modelis?
• Kad izmantot Singleton metodes dizaina modeli?
• Singletona inicializācijas veidi
• Singleton metodes dizaina modeļa galvenā sastāvdaļa:
• Singleton Method Design Pattern ieviešana
• Dažādi veidi, kā ieviest Singleton metodes dizaina modeli
• Singletona metodes izmantošanas gadījums
• Singleton metodes dizaina modeļa priekšrocības:
• Singleton dizaina modeļa trūkumi

1. Kas ir Singleton Method Design Pattern?

Singleton metode jeb Singleton Design modelis ir viens no vienkāršākajiem dizaina modeļiem. Tas nodrošina, ka klasei ir tikai viens gadījums, un nodrošina tai globālu piekļuves punktu.

2. Kad izmantot Singleton Method Design Pattern?

Izmantojiet Singltona metodes dizaina modeli, ja:

dizaina modeļi Java

• Jābūt tieši vienam klases gadījumam, un tai ir jābūt pieejamai klientiem no labi zināma piekļuves punkta.
• Kad vienīgajai instancei ir jābūt paplašināmai, klasificējot apakšklasi, un klientiem vajadzētu būt iespējai izmantot paplašinātu gadījumu bez izmaiņām
• Singleton klases tiek izmantotas reģistrēšanai, draiveru objektiem, kešatmiņai un pavedienu pūlam, datu bāzes savienojumiem.

3. Singletona inicializācijas veidi

Singleton klasi var izveidot ar divām metodēm:

noņemiet npm kešatmiņu

• Agrīna inicializācija: Šajā metodē klase tiek inicializēta neatkarīgi no tā, vai tā ir jāizmanto vai nē. Šīs metodes galvenā priekšrocība ir tās vienkāršība. Jūs uzsākat nodarbību klases ielādes laikā. Tās trūkums ir tāds, ka klase vienmēr tiek inicializēta neatkarīgi no tā, vai tā tiek izmantota vai nē.
• Slinka inicializācija: Izmantojot šo metodi, klasi inicializē tikai tad, kad tas ir nepieciešams. Tas var pasargāt jūs no mācību priekšmeta izveides, kad jums tas nav vajadzīgs. Parasti slinka inicializēšana tiek izmantota, kad mēs veidojam viena klase.

4. Singleton metodes dizaina modeļa galvenā sastāvdaļa:

4.1. Statisks dalībnieks:

Singleton modelis vai modelis Singleton nodarbina statisku dalībnieku klasē. Šis statiskais elements nodrošina, ka atmiņa tiek piešķirta tikai vienu reizi, saglabājot vienu Singleton klases gadījumu.

// Static member to hold the single instance private static Singleton instance;>

4.2. Privātais konstruktors:

Singleton raksts vai raksts singleton ietver privātu konstruktoru, kas kalpo kā barikāde pret ārējiem mēģinājumiem izveidot Singleton klases gadījumus. Tas nodrošina, ka klasei ir iespēja kontrolēt savu inscenēšanas procesu.

// Private constructor to // prevent external instantiation class Singleton {  // Making the constructor as Private  private Singleton()  {  // Initialization code here  } }>

4.3. Statiskā rūpnīcas metode:

Būtisks Singltona modeļa aspekts ir statiskās rūpnīcas metodes klātbūtne. Šī metode darbojas kā vārteja, nodrošinot globālu piekļuves punktu Singleton objektam. Kad kāds pieprasa instanci, šī metode vai nu izveido jaunu instanci (ja tāda nav), vai arī atgriež esošo gadījumu zvanītājam.

// Static factory method for global access public static Singleton getInstance() {  // Check if an instance exists  if (instance == null) {  // If no instance exists, create one  instance = new Singleton();  }  // Return the existing instance  return instance; }>

5. Singleton Method Design Pattern ieviešana

Singleton Design Pattern vai Pattern Singleton ieviešana ir aprakstīta šādā klašu diagrammā:

Singleton Method Design Pattern ieviešana

1 līdz 100 romiešu Nr

Viena dizaina modeļa ieviešana ir ļoti vienkārša un sastāv no vienas klases. Lai nodrošinātu, ka atsevišķais gadījums ir unikāls, visi viengabala konstruktori ir jāpadara privāti. Globālā piekļuve tiek veikta, izmantojot statisku metodi, kurai var globāli piekļūt vienai instancei, kā parādīts kodā.

/*package whatever //do not write package name here */ import java.io.*; class Singleton {  // static class  private static Singleton instance;  private Singleton()  {  System.out.println('Singleton is Instantiated.');  }  public static Singleton getInstance()  {  if (instance == null)  instance = new Singleton();  return instance;  }  public static void doSomething()  {  System.out.println('Somethong is Done.');  } } class GFG {  public static void main(String[] args)  {  Singleton.getInstance().doSomething();  } }>

Singleton is Instantiated. Somethong is Done.>

Izmantojot metodi getInstance, mēs pārbaudām, vai gadījums ir nulle. Ja instancē nav nulles, tas nozīmē, ka objekts tika izveidots iepriekš; pretējā gadījumā mēs to izveidojam, izmantojot jauno operatoru.

6. Dažādi veidi, kā ieviest Singleton metodes dizaina modeli

Dažreiz mums ir nepieciešams tikai viens mūsu klases gadījums, piemēram, viens DB savienojums, ko koplieto vairāki objekti, jo atsevišķa DB savienojuma izveide katram objektam var būt dārga. Tāpat lietojumprogrammā var būt viens konfigurācijas pārvaldnieks vai kļūdu pārvaldnieks, kas apstrādā visas problēmas, nevis izveido vairākus pārvaldniekus.

Apskatīsim dažādas dizaina iespējas šādas klases ieviešanai. Ja jums ir labi pārzināt statiskos klases mainīgos un piekļuves modifikatorus, tam nevajadzētu būt grūtam uzdevumam.

sīklietotne sīklietotne

1. metode – klasiskā ieviešana || Padariet getInstance() statisku, lai to ieviestu Singleton metodes dizaina modelis

// Classical Java implementation of singleton // design pattern class Singleton {  private static Singleton obj;  // private constructor to force use of  // getInstance() to create Singleton object  private Singleton() {}  public static Singleton getInstance()  {  if (obj == null)  obj = new Singleton();  return obj;  } }>

Šeit mēs esam paziņojuši getInstance() statisks, lai mēs to varētu nosaukt, neveidojot klasi. Pirmā reize getInstance() tiek saukts, tas rada jaunu viena objekta objektu un pēc tam tikai atgriež to pašu objektu.

Piezīme: Singleton obj netiek izveidots, kamēr mums tas nav vajadzīgs un izsaukts getInstance() metodi. To sauc par slinku instantiāciju. Galvenā problēma ar iepriekš minēto metodi ir tā, ka tā nav droša pavedienam. Apsveriet šādu izpildes secību.

Šī izpildes secība rada divus objektus viengabalam. Tāpēc šī klasiskā ieviešana nav droša.

2. metode || Sinhronizējiet getInstance(), lai to ieviestu Singleton metodes dizaina modelis

// Thread Synchronized Java implementation of // singleton design pattern class Singleton {  private static Singleton obj;  private Singleton() {}  // Only one thread can execute this at a time  public static synchronized Singleton getInstance()  {  if (obj == null)  obj = new Singleton();  return obj;  } }>

Šeit, izmantojot sinhronizāciju, tiek nodrošināts, ka vienlaikus var izpildīt tikai vienu pavedienu getInstance() . Šīs metodes galvenais trūkums ir tāds, ka sinhronizācijas izmantošana katru reizi, veidojot vienu objektu, ir dārga un var samazināt programmas veiktspēju. Tomēr, ja veiktspēja getInstance() nav būtiska jūsu lietojumprogrammai, šī metode nodrošina tīru un vienkāršu risinājumu.

3. metode — dedzīga instantiācija || Uz statiskā inicializatora balstīta viena dizaina modeļa ieviešana

// Static initializer based Java implementation of // singleton design pattern class Singleton {  private static Singleton obj = new Singleton();  private Singleton() {}  public static Singleton getInstance() { return obj; } }>

Šeit mēs esam izveidojuši viengabala gadījumu statiskā inicializatorā. JVM izpilda statisku inicializatoru, kad klase ir ielādēta, un tādējādi tiek garantēts, ka tas ir drošs pavedienam. Izmantojiet šo metodi tikai tad, ja vienreizējā klase ir viegla un tiek izmantota visas programmas izpildes laikā.

4. metode – visefektīvākā || Izmantojiet dubultā pārbaudīto bloķēšanu, lai ieviestu viengabala dizaina modeli

Ja pamanāt uzmanīgi, kad objekts ir izveidots, sinhronizācija vairs nav noderīga, jo tagad obj nebūs nulles un jebkura darbību secība radīs konsekventus rezultātus. Tātad mēs iegūsim tikai vienu reizi getInstance() bloķēšanu, ja objekts ir nulle. Tādā veidā mēs sinhronizējam tikai pirmo ceļu, tieši to, ko vēlamies.

slēdža korpuss java

// Double Checked Locking based Java implementation of // singleton design pattern class Singleton {  private static volatile Singleton obj = null;  private Singleton() {}  public static Singleton getInstance()  {  if (obj == null) {  // To make thread safe  synchronized (Singleton.class)  {  // check again as multiple threads  // can reach above step  if (obj == null)  obj = new Singleton();  }  }  return obj;  } }>

Esam deklarējuši obj nepastāvīgs kas nodrošina, ka vairāki pavedieni pareizi piedāvā mainīgo obj, kad tas tiek inicializēts Singleton instancē. Šī metode krasi samazina pieskaitāmās izmaksas, kas rodas, katru reizi izsaucot sinhronizēto metodi.

7. Singleton metodes izmantošanas gadījums

• Datu bāzes savienojumi: Lietojumprogrammās, kurās datu bāzes savienojumu izveide un pārvaldība ir dārga darbība, Singleton var izmantot, lai visā lietojumprogrammā uzturētu vienotu datu bāzes savienojumu.
• Konfigurācijas pārvaldība: Ja jums ir globālie konfigurācijas iestatījumi, kuriem ir jāpiekļūst dažādiem lietojumprogrammas komponentiem, Singleton konfigurācijas pārvaldnieks var nodrošināt vienu piekļuves punktu šiem iestatījumiem.
• GUI komponenti: Grafiskā lietotāja interfeisa (GUI) komponentiem vai kontrolleriem Singleton var palīdzēt pārvaldīt lietotāja interfeisa stāvokli un darbības, nodrošinot vienu kontroles punktu.
• Ierīču pārvaldnieki: Iegultās sistēmās vai lietojumprogrammās, kas mijiedarbojas ar aparatūras ierīcēm, Singleton var izmantot, lai pārvaldītu un kontrolētu piekļuvi aparatūras ierīcēm, lai izvairītos no konfliktiem.
• Drukas pakalpojums: Sistēmās, kas ietver dokumentu vai atskaišu drukāšanu, Singleton drukas pakalpojums var koordinēt un pārvaldīt drukas darbus, nodrošinot efektīvu drukas resursu izmantošanu.

8. Singleton metodes dizaina modeļa priekšrocības:

• Atrisina vārdu sadursmes: Gadījumos, kad ir nepieciešams viens kontroles punkts, lai izvairītos no nosaukšanas konfliktiem vai sadursmēm, Singleton modelis nodrošina, ka ir tikai viens gadījums ar unikālu nosaukumu.
• Dedzīga vai slinka inicializācija: Singleton modelis atbalsta gan dedzīgu inicializēšanu (gadījuma izveide, kad klase ir ielādēta), gan slinku inicializāciju (instanču izveidošana, kad tā tiek pirmo reizi pieprasīta), nodrošinot elastību atkarībā no lietošanas gadījuma.
• Vītnes drošība: Pareizi ieviesti Singleton modeļi var nodrošināt pavedienu drošību, nodrošinot, ka gadījums tiek izveidots atomiski un ka vairāki pavedieni netīšām neveido gadījumu dublikātus.
• Samazināts atmiņas apjoms: Lietojumprogrammās, kurās resursu patēriņš ir kritisks, Singleton modelis var samazināt atmiņas nospiedumu, nodrošinot, ka ir tikai viens klases gadījums.

9. Singleton Design Pattern trūkumi

• Pārbaudes grūtības: Tā kā Singletons ievieš globālu stāvokli, vienību pārbaude var kļūt sarežģīta. Viena komponenta pārbaude atsevišķi var būt sarežģītāka, ja tā balstās uz Singleton, jo Singleton stāvoklis var ietekmēt testu rezultātus.
• Vienlaicības problēmas: Vidē ar vairākiem pavedieniem var rasties problēmas, kas saistītas ar Singleton instances izveidi un inicializāciju. Ja vairāki pavedieni mēģina izveidot Singleton vienlaikus, tas var izraisīt sacensību apstākļus.
• Ierobežota paplašināšana: Singleton modelis var padarīt kodu mazāk paplašināmu. Ja vēlāk nolemjat, ka jums ir nepieciešami vairāki klases gadījumi vai vēlaties mainīt inscenēšanas loģiku, var būt nepieciešama būtiska pārveidošana.
• Globālā atkarība: Singleton modelis rada globālu atkarību, apgrūtinot Singleton aizstāšanu ar alternatīvu ieviešanu vai atkarības injekcijas izmantošanu gadījumu nodrošināšanai.
• Grūti iekļaut apakšklasē: Singleton apakšklase var būt sarežģīta. Tā kā konstruktors parasti ir privāts, Singleton paplašināšana prasa papildu piesardzību un var neatbilst standarta mantojuma modeļiem.
• Dzīves cikla pārvaldība: Singleton modelis var neapstrādāt scenārijus, kad gadījums ir skaidri jāiznīcina vai jāatiestata. Singleton dzīves cikla pārvaldība var kļūt par bažām.
• Globālā piekļuves punkta ļaunprātīga izmantošana: Lai gan globālais piekļuves punkts ir priekšrocība, to var arī ļaunprātīgi izmantot. Izstrādātājiem varētu rasties kārdinājums izmantot Singleton visam, izraisot globālā stāvokļa pārmērīgu izmantošanu un mazāk modulāru dizainu.

10. Secinājums

Ir svarīgi, lai dažām klasēm būtu tieši viens gadījums. Lai gan sistēmā var būt daudz printeru, printera spolētājam vajadzētu būt tikai vienam. Jābūt tikai vienai failu sistēmai un vienam logu pārvaldniekam. Digitālajam filtram būs viens A/D pārveidotājs. Viena uzņēmuma apkalpošanai būs paredzēta grāmatvedības sistēma. Kā nodrošināt, lai klasei būtu tikai viens gadījums un ka tā būtu viegli pieejama? Globālais mainīgais padara objektu pieejamu, taču tas neliedz jums izveidot vairākus objektus.

Labāks risinājums ir likt klasei pašai atbildību par savas vienīgās instances izsekošanu. Klase var nodrošināt, ka nevar izveidot nevienu citu instanci (pārtverot pieprasījumus izveidot jaunus objektus), un tā var nodrošināt veidu, kā piekļūt instancei. Šis ir Singltona modelis.