Singleton: Nasıl kullanılmalı

Düzenleme: Başka bir sorudan singletons hakkında birçok soru / cevap bağlantıları olan bir cevap sağladım: Singletons hakkında daha fazla bilgi burada:

Bu yüzden konu okudum Singletons: iyi tasarım veya koltuk değneği?
Ve tartışma hâlâ devam ediyor.

Tekilleri Tasarım Deseni olarak görüyorum (iyi ve kötü).

Singleton ile ilgili sorun Kalıp değil, kullanıcılar (özür dileriz). Herkes ve babaları bir tanesini doğru bir şekilde uygulayabileceklerini düşünüyor (ve yaptığım birçok röportajdan çoğu insan yapamıyor). Ayrıca herkes doğru bir Singleton uygulayabileceğini düşündüğü için Deseni kötüye kullanır ve uygun olmayan durumlarda kullanır (global değişkenleri Singletons ile değiştirir!).

Bu yüzden cevaplanması gereken ana sorular:

• Ne zaman Singleton kullanmalısın
• Bir Singleton'u doğru şekilde nasıl uygularsınız

Bu yazı için umudum, tek bir yerde (google ve birden fazla sitede arama yapmak yerine) tek bir yerde toplayabilmemizdir. Ayrıca, neden işe yaramadıklarını ve iyi uygulamalar için zayıflıklarını açıklayan Anti-Usages ve yaygın kötü uygulamaların bir listesi de uygun olacaktır.

Bu yüzden topu yuvarlayın:
Elimi tutup kullanacağımı söyleyeceğim ama muhtemelen problemleri var.
"Etkili C ++" kitaplarında konunun "Scott Myers" kullanımını seviyorum

Singleton kullanmak için iyi durumlar (çok değil):

• Günlük çerçeveleri
• İplik geri dönüşüm havuzları

/*
 * C++ Singleton
 * Limitation: Single Threaded Design
 * See: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
 *      For problems associated with locking in multi threaded applications
 *
 * Limitation:
 * If you use this Singleton (A) within a destructor of another Singleton (B)
 * This Singleton (A) must be fully constructed before the constructor of (B)
 * is called.
 */
class MySingleton
{
    private:
        // Private Constructor
        MySingleton();
        // Stop the compiler generating methods of copy the object
        MySingleton(MySingleton const& copy);            // Not Implemented
        MySingleton& operator=(MySingleton const& copy); // Not Implemented

    public:
        static MySingleton& getInstance()
        {
            // The only instance
            // Guaranteed to be lazy initialized
            // Guaranteed that it will be destroyed correctly
            static MySingleton instance;
            return instance;
        }
};

TAMAM. Biraz eleştiri ve diğer uygulamaları bir araya getirelim.
:-)

Hepiniz yanılıyorsunuz. Soruyu okuyun. Cevap:

Aşağıdaki durumlarda bir Singleton kullanın:

• Sistemde bir türden yalnızca bir nesne olması gerekir

Aşağıdaki durumlarda Singleton kullanmayın:

• Hafızadan tasarruf etmek istiyorsunuz
• Yeni bir şey denemek istiyorsun
• Ne kadar bildiğini göstermek istiyorsun
• Çünkü herkes bunu yapıyor (Bkz . Wikipedia'da kargo kült programcısı )
• Kullanıcı arayüzü widget'larında
• Önbellek olması gerekiyordu
• Dizelerde
• Oturumlarda
• Gün boyu gidebilirim

En iyi singleton nasıl oluşturulur:

• Daha küçük, daha iyi. Ben minimalistim
• İpliğin güvenli olduğundan emin olun
• Asla boş olmadığından emin ol
• Yalnızca bir kez oluşturulduğundan emin olun
• Tembel veya sistem başlatma? İhtiyaçlarınıza kadar
• Bazen işletim sistemi veya JVM sizin için singleton oluşturur (örneğin Java'da her sınıf tanımı bir singletondur)
• Bir yıkıcı sağlayın veya bir şekilde kaynakları nasıl atacağınızı öğrenin
• Çok az bellek kullanın

Teklitonlar, iki kötü özelliği bir sınıfta birleştirebilmenizi sağlar. Bu hemen hemen her şekilde yanlış.

Bir singleton size şunları sağlar:

1. Bir nesneye küresel erişim ve
2. Bu türden birden fazla nesnenin oluşturulamayacağının garantisi

Bir numara anlaşılır. Globaller genellikle kötüdür. Gerçekten ihtiyacımız olmadıkça, nesneleri asla küresel olarak erişilebilir yapmamalıyız .

İkincisi mantıklı gelebilir, ama düşünelim. En son ne zaman mevcut bir nesneye başvurmak yerine yanlışlıkla yeni bir nesne oluşturdunuz? Bu C ++ olarak etiketlendiğinden, bu dilden bir örnek kullanalım. Sıklıkla yanlışlıkla yazar mısın

std::ostream os;
os << "hello world\n";

Ne zaman yazmak istedin?

std::cout << "hello world\n";

Tabii ki değil. Bu hataya karşı korumaya ihtiyacımız yok, çünkü bu tür bir hata oluşmuyor. Eğer öyleyse, doğru cevap eve gitmek ve 12-20 saat uyumak ve daha iyi hissetmenizi ummaktır.

Yalnızca bir nesneye ihtiyaç duyulursa, yalnızca bir örnek oluşturun. Bir nesneye global olarak erişilebilir olması gerekiyorsa, onu global yapın. Ancak bu, başka örnekleri oluşturmanın imkansız olması gerektiği anlamına gelmez.

"Tek bir örnek mümkündür" kısıtı bizi olası hatalara karşı gerçekten korumaz. Ama yok gözden geçirmeniz çok sert kodumuzu yapmak ve sürdürmek. Oldukça sık öğrenmek Çünkü sonradan daha bir örneği değil gerek yoktu söyledi. Biz bunu biz birden fazla veritabanı var mı , biz birkaç kaydediciler birden fazla yapılandırma nesnesi istiyorsun var. Birim testlerimiz, ortak bir örnek olarak her testte bu nesneleri oluşturabilir ve yeniden oluşturabilir.

Bir tekil ancak ve ancak kullanılması gerektiğini Yani ihtiyacımız hem sunduğu özellikleri: Biz ise gerek küresel erişimi (globaller genellikle tavsiye edilmez, çünkü nadir olduğu) ve biz ihtiyacımız kimse önlemek için şimdiye a birden fazla örneğini oluşturarak (bana bir tasarım sorunu gibi geliyor). Bunun için görebilmemin tek nedeni, iki örnek oluşturmanın uygulama durumumuzu bozmasıdır - muhtemelen sınıf bir dizi statik üye veya benzer bir saçmalık içerdiğinden. Bu durumda bariz cevap bu sınıfı düzeltmektir. Tek örnek olmaya bağlı olmamalı.

Bir nesneye global erişime ihtiyacınız varsa, onu global gibi yapın std::cout. Ancak oluşturulabilecek örnek sayısını kısıtlamayın.

Kesinlikle, bir sınıfın örnek sayısını bir taneyle sınırlamanız gerekiyorsa ve ikinci bir örnek oluşturmanın güvenli bir şekilde ele alınmasının bir yolu yoksa, bunu zorlayın. Ancak küresel olarak da erişilebilir yapmayın.

Her iki özelliğe de ihtiyacınız varsa, o zaman 1) bunu tek birton haline getirin ve 2) bana bunun için neye ihtiyacınız olduğunu bildirin, çünkü böyle bir durumu hayal etmekte zorlanıyorum.

Tektonlarla ilgili sorun onların uygulanması değildir. İkisi de açıkça istenen iki farklı kavramı birleştiriyorlar.

1) Tektonlar bir nesneye genel erişim mekanizması sağlar. İyi tanımlanmış bir başlatma sırası olmayan dillerde marjinal olarak daha güvenli veya marjinal olarak daha güvenilir olmalarına rağmen, bu kullanım hala küresel bir değişkenin ahlaki eşdeğeridir. Bu, bazı garip sözdiziminde (g_foo yerine demek) foo :: get_instance () giyinmiş küresel bir değişkendir, ancak aynı amaca hizmet eder (tüm programda erişilebilir tek bir nesne) ve aynı dezavantajlara sahiptir.

2) Tektonlar bir sınıfın birden çok örneğini önler. IME, bu tür özelliklerin bir sınıfa dönüştürülmesi nadirdir. Normalde çok daha bağlamsal bir şeydir; bire bir olarak kabul edilen birçok şey gerçekten sadece bire bir olur. IMO daha uygun bir çözüm, yalnızca birden fazla örneğe ihtiyacınız olduğunu fark edene kadar yalnızca bir örnek oluşturmaktır.

Desenli bir şey: genelleme . Yararlı oldukları ve başarısız oldukları zaman tüm vakaları vardır.

Singleton , kodu test etmeniz gerektiğinde kötü olabilir . Genellikle sınıfın bir örneğiyle sıkışıp kalıyorsunuz ve yapıcıda bir kapı açmak veya durumu sıfırlamak için bazı yöntemler arasında seçim yapabilirsiniz.

Diğer sorun, Singleton'un aslında kılık değiştirmiş küresel bir değişkenten başka bir şey olmamasıdır . Programınız üzerinde çok fazla küresel ortak durumunuz olduğunda, işler geri dönme eğilimindedir, hepimiz biliyoruz.

Bu yapabilir izleme bağımlılık zor. Her şey Singleton'unuza bağlı olduğunda, onu değiştirmek, ikiye bölmek vb. Daha zordur. Genellikle onunla sıkışıp kalırsınız. Bu aynı zamanda esnekliği de engeller. Bu sorunu hafifletmek için bazı Bağımlılık Enjeksiyonu çerçevesini araştırın .

Singletons temel olarak, karmaşık küresel değişkenlere sahip olmanızı zorlaştıran veya olanaksız hale getiren dillerde karmaşık küresel duruma sahip olmanızı sağlar.

Özellikle Java, global değişkenlerin yerine singleton kullanır, çünkü her şey bir sınıf içinde yer almalıdır. Global değişkenlere en yakın, genel statik değişkenlerdir ve bunlar küreselmiş gibi kullanılabilir.import static

C ++ genel değişkenlere sahiptir, ancak genel sınıf değişkenlerinin kurucularının çağrılma sırası tanımsızdır. Bu nedenle, bir singleton, bu değişkene ilk ihtiyaç duyulana kadar bir global değişkenin oluşturulmasını ertelemenizi sağlar.

Python ve Ruby gibi diller tektonları çok az kullanır, çünkü bunun yerine bir modül içindeki global değişkenleri kullanabilirsiniz.

Peki ne zaman bir singleton kullanmak iyi / kötü? Hemen hemen küresel bir değişken kullanmanın iyi / kötü olacağı zaman.

Alexandrescu tarafından tasarlanan modern C ++ Design , iş parçacığı açısından güvenli, kalıtsal bir jenerik singletona sahiptir.

2p değere göre, teklitonlarınız için yaşam sürelerini tanımlamanızın önemli olduğunu düşünüyorum (bunları kullanmak için kesinlikle gerekli olduğunda). Normalde statik get()fonksiyonun hiçbir şey başlatmasına izin vermem ve kurulum ve yıkımı ana uygulamanın bazı özel bölümlerine bırakmam. Bu, tektonlar arasındaki bağımlılıkları vurgulamaya yardımcı olur - ancak yukarıda vurgulandığı gibi, mümkünse bunlardan kaçınmak en iyisidir.

• Bir Singleton'u doğru şekilde nasıl uygularsınız

Daha önce hiç görmediğim bir konu var, bir önceki işte karşılaştığım bir şey. DLL'ler arasında paylaşılan C ++ singletonları vardı ve bir sınıfın tek bir örneğinin çalışmadığından emin olmanın olağan mekanikleri işe yaramadı. Sorun, her DLL EXE ile birlikte kendi statik değişkenler kümesi olmasıdır. Get_instance işleviniz satır içi veya statik kitaplığın parçasıysa, her DLL kendi "singleton" kopyasıyla dolar.

Çözüm, singleton kodunun yalnızca bir DLL veya EXE'de tanımlandığından emin olmak veya örnekleri çözümlemek için bu özelliklere sahip tek bir yönetici oluşturmaktır.

İlk örnek iş parçacığı için güvenli değildir - iki iş parçacığı aynı anda getInstance öğesini çağırırsa, bu statik bir PITA olacaktır. Bir çeşit muteks yardımcı olabilir.

Diğerlerinin de belirttiği gibi, tektonların büyük dezavantajları, bunları genişletememe ve birden fazla örneği örnekleme gücünü kaybetme, örneğin test amaçlıdır.

Tektonların bazı yararlı yönleri:

1. tembel veya açık örnekleme
2. kurulum ve / veya durum gerektiren bir nesne için kullanışlı

Ancak, bu avantajlardan yararlanmak için bir singleton kullanmanız gerekmez. İşi yapan normal bir nesne yazabilir ve sonra insanların bir fabrika (ayrı bir nesne) üzerinden erişmesini sağlayabilirsiniz. Fabrika, gerektiğinde yalnızca birini örnekleme ve yeniden kullanma vb. Ayrıca, somut bir sınıftan ziyade bir arayüze program yaparsanız, fabrika stratejileri kullanabilir, yani arayüzün çeşitli uygulamalarını açıp kapatabilirsiniz.

Son olarak, bir fabrika kendini Spring vs. gibi bağımlılık enjeksiyon teknolojilerine borçludur.

Singletons, başlattığınızda ve itiraz ederken çok sayıda kod çalıştırıldığında kullanışlıdır. Örneğin, bir kalıcılık nesnesi ayarlarken iBatis'i kullanırken, kodunuza gelmeden önce tüm yapılandırmaları okumalı, haritaları ayrıştırmalı, hepsinin doğru olduğundan emin olmalısınız.

Bunu her seferinde yaparsanız performans çok düşecektir. Tek birtonda kullanarak, bu isabeti bir kez alırsınız ve sonraki tüm aramaların bunu yapması gerekmez.

Singletons'un asıl çöküşü kalıtımdan kopmalarıdır. Singleton'a başvuruda bulunulan koda erişiminiz yoksa, size genişletilmiş işlevsellik sağlamak için yeni bir sınıf türetemezsiniz. Bu nedenle, Singleton kodunuzu sıkıca bağlayacak olmasının ötesinde (bir Strateji Deseni ... yani Bağımlılık Enjeksiyonu ile sabitlenebilir), kodun bölümlerini revizyondan (paylaşılan kütüphaneler) kapatmanızı da önleyecektir.

Bu nedenle, günlük veya iş parçacığı havuzlarının örnekleri bile geçersizdir ve bunların yerine Stratejiler kullanılmalıdır.

Çoğu insan küresel bir değişken kullanma konusunda kendilerini iyi hissetmeye çalışırken singletonları kullanır. Meşru kullanımlar vardır, ancak çoğu zaman insanlar bunları kullandıklarında, sadece bir örnek olabileceği gerçeği, küresel olarak erişilebilir olduğu gerçeğine kıyasla sadece önemsiz bir gerçektir.

Tek birton yalnızca bir örneğin oluşturulmasına izin verdiğinden, örnek çoğaltmasını etkin bir şekilde kontrol eder. örneğin, bir aramanın birden fazla örneğine ihtiyacınız olmaz - örneğin, bir mors arama haritası, böylece tek bir sınıfta sarmak uygundur. Ve sınıfın tek bir örneğine sahip olmanız, o örneğe yapılan başvuruların sayısıyla sınırlı olduğunuz anlamına gelmez. Örneğe çağrıları (iş parçacığı sorunlarını önlemek için) sıralayabilir ve gerekli efekt değişikliklerini yapabilirsiniz. Evet, bir singletonun genel biçimi küresel olarak herkese açık bir formdur, daha sınırlı bir singleton oluşturmak için tasarımı kesinlikle değiştirebilirsiniz. Bunu daha önce hiç yormadım ama eminim ki mümkün. Ve singleton deseninin tamamen kötü olduğunu söyleyen herkese şunu bilmelisiniz:

Ancak Singleton gibi bir şeye ihtiyacım olduğunda, genellikle bunu başlatmak için bir Schwarz Sayacı kullanıyorum .

Aşağıda, hafızayı yıkıcıda yeniden konumlandıran, iş parçacığı için güvenli bir tekli model uygulamak için daha iyi bir yaklaşım bulunmaktadır. Ancak yıkıcı isteğe bağlı olmalıdır, çünkü program sona erdiğinde singleton örneği otomatik olarak yok edilecektir:

#include<iostream>
#include<mutex>

using namespace std;
std::mutex mtx;

class MySingleton{
private:
    static MySingleton * singletonInstance;
    MySingleton();
    ~MySingleton();
public:
    static MySingleton* GetInstance();
    MySingleton(const MySingleton&) = delete;
    const MySingleton& operator=(const MySingleton&) = delete;
    MySingleton(MySingleton&& other) noexcept = delete;
    MySingleton& operator=(MySingleton&& other) noexcept = delete;
};

MySingleton* MySingleton::singletonInstance = nullptr;
MySingleton::MySingleton(){ };
MySingleton::~MySingleton(){
    delete singletonInstance;
};

MySingleton* MySingleton::GetInstance(){
    if (singletonInstance == NULL){
        std::lock_guard<std::mutex> lock(mtx);
        if (singletonInstance == NULL)
            singletonInstance = new MySingleton();
    }
    return singletonInstance;
}

Tekli sınıfları kullanmamız gereken durumlarla ilgili olarak şunlar olabilir: Programın yürütülmesi sırasında örneğin durumunu korumak istiyorsak, dosyanın yalnızca bir örneğinin gerekli olduğu bir uygulamanın yürütme günlüğüne yazmakla ilgileniyorsak kullanılabilir .... vb. Yukarıdaki kodumda optimizasyon önerisi olup olmadığı takdir edilecektir.

Singletons'ı röportaj testi olarak kullanıyorum.

Bir geliştiriciden tasarım desenlerini adlandırmasını istediğimde, isimlendirebilecekleri tek Singleton ise işe alınmaz.

Anti-Kullanımı:

Aşırı tek ton kullanımıyla ilgili önemli bir sorun, modelin alternatif uygulamaların kolayca genişletilmesini ve değiştirilmesini önlemesidir. Sınıf adı, singletonun kullanıldığı her yerde sabit kodlanmıştır.

Bu C # için en sağlam sürüm olduğunu düşünüyorum :

using System;
using System.Collections;
using System.Threading;

namespace DoFactory.GangOfFour.Singleton.RealWorld
{

  // MainApp test application

  class MainApp
  {
    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Same instance?
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 server requests
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // "Singleton"

  class LoadBalancer
  {
    private static LoadBalancer instance;
    private ArrayList servers = new ArrayList();

    private Random random = new Random();

    // Lock synchronization object
    private static object syncLock = new object();

    // Constructor (protected)
    protected LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      // Support multithreaded applications through
      // 'Double checked locking' pattern which (once
      // the instance exists) avoids locking each
      // time the method is invoked
      if (instance == null)
      {
        lock (syncLock)
        {
          if (instance == null)
          {
            instance = new LoadBalancer();
          }
        }
      }

      return instance;
    }

    // Simple, but effective random load balancer

    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

İşte .NET için optimize edilmiş sürüm :

using System;
using System.Collections;

namespace DoFactory.GangOfFour.Singleton.NETOptimized
{

  // MainApp test application

  class MainApp
  {

    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Confirm these are the same instance
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 requests for a server
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // Singleton

  sealed class LoadBalancer
  {
    // Static members are lazily initialized.
    // .NET guarantees thread safety for static initialization
    private static readonly LoadBalancer instance =
      new LoadBalancer();

    private ArrayList servers = new ArrayList();
    private Random random = new Random();

    // Note: constructor is private.
    private LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      return instance;
    }

    // Simple, but effective load balancer
    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

Bu kalıbı dotfactory.com adresinde bulabilirsiniz .

Meyers singleton deseni çoğu zaman yeterince iyi çalışır ve bazen daha iyi bir şey aramak için ödeme yapmaz. Yapıcı asla atmayacağı ve singletonlar arasında bağımlılık olmadığı sürece.

Tekilton, tüm GAO'lar tekil olmasa da, küresel olarak erişilebilir bir nesne (bundan sonra GAO) için bir uygulamadır .

Kaydedicilerin kendileri tekil olmamalı, ancak günlük iletisinin nereden veya nasıl kaydedildiği yerden ayrıştırmak için günlük araçlarına ideal olarak küresel erişilebilir olmalıdır.

Tembel yükleme / tembel değerlendirme farklı bir kavramdır ve singleton genellikle bunu da uygular. Özellikle iş parçacığı güvenliği ve istisnalarla başarısız olursa, o zaman iyi bir fikir gibi görünen şeylerin o kadar da büyük olmadığı ortaya çıkar. (Dizelerde COW uygulaması gibi).

Bunu akılda tutarak, GOA'lar şu şekilde başlatılabilir:

namespace {

T1 * pt1 = NULL;
T2 * pt2 = NULL;
T3 * pt3 = NULL;
T4 * pt4 = NULL;

}

int main( int argc, char* argv[])
{
   T1 t1(args1);
   T2 t2(args2);
   T3 t3(args3);
   T4 t4(args4);

   pt1 = &t1;
   pt2 = &t2;
   pt3 = &t3;
   pt4 = &t4;

   dostuff();

}

T1& getT1()
{
   return *pt1;
}

T2& getT2()
{
   return *pt2;
}

T3& getT3()
{
  return *pt3;
}

T4& getT4()
{
  return *pt4;
}

Bu kadar kabaca yapılmasına gerek yoktur ve nesneleri içeren yüklü bir kütüphanede, ömürlerini yönetmek için muhtemelen başka bir mekanizma olmasını istersiniz. (Kütüphaneyi yüklediğinizde aldığınız bir nesneye koyun).

Teklitonları ne zaman kullanacağım? Onları 2 şey için kullandım - dlopen ile hangi kitaplıkların yüklendiğini gösteren tek bir tablo - Kaydedicilerin abone olabileceği ve mesaj gönderebileceğiniz bir mesaj işleyici. Özellikle sinyal işleyiciler için gereklidir.

Hala neden bir singletonun küresel olması gerektiğini anlamıyorum.

Ben bir özel sabit statik değişken olarak sınıf içinde bir veritabanı sakladı ve hiç kullanıcıya veritabanı maruz kalmadan veritabanını kullanan sınıf işlevleri yapmak bir singleton üretecekti.

Bu işlevin neden kötü olacağını anlamıyorum.

Çok fazla belleğe sahip bir sınıfım olduğunda onları kullanışlı buluyorum. Örneğin son zamanlarda üzerinde çalıştığım bir oyunda, bitişik belleğin çok büyük dizilerini içeren bir etki haritası sınıfım var. Ben başlangıçta tüm tahsis istiyorum, tüm kapanışta serbest ve kesinlikle sadece bir kopyasını istiyorum. Aynı zamanda birçok yerden de erişmem gerekiyor. Singleton paterninin bu durumda çok faydalı olduğunu düşünüyorum.

Eminim başka çözümler de var ama bunu çok kullanışlı ve kolay uygulanabilir buluyorum.

Eğer singletonu yaratan ve onu kullanan sizseniz, bunu singleton olarak yapmayın (mantıklı değildir çünkü nesnenin tekilliğini singleton yapmadan kontrol edebilirsiniz) ama bir geliştiricinin ve kullanıcılarınıza yalnızca bir nesne sağlamak istiyorsunuz (bu durumda singletonu kim oluşturuyorsunuz, ancak kullanıcı siz değilsiniz).

Singletons nesnelerdir, bu yüzden onları nesne olarak kullanın, birçok kişi doğrudan döndüren yöntemi çağırarak singletonlara erişir, ancak bu zararlıdır, çünkü kodunuzu nesnenin singleton olduğunu bilirsiniz, singletonları nesne olarak kullanmayı tercih ederim, onları geçiyorum yapıcı aracılığıyla ve onları sıradan nesneler olarak kullanıyorum, bu şekilde, kodunuz bu nesnelerin tekil olup olmadığını bilmiyor ve bu bağımlılıkları daha net hale getiriyor ve yeniden düzenleme için biraz yardımcı oluyor ...

Masaüstü uygulamalarında (artık sadece dinozorlar bunları yazıyor!) Nispeten değişmeyen küresel uygulama ayarları elde etmek için şarttır - aksi takdirde her sınıfa ve her diyaloga girmek zorunda kalacak kullanıcı dili, yardım dosyalarına yol, kullanıcı tercihleri ​​vb. .

Düzenle - elbette bunlar salt okunur olmalıdır!

Başka bir uygulama

class Singleton
{
public:
    static Singleton& Instance()
    {
        // lazy initialize
        if (instance_ == NULL) instance_ = new Singleton();

        return *instance_;
    }

private:
    Singleton() {};

    static Singleton *instance_;
};