it-swarm-tr.com

Yani Singletons kötü, o zaman ne?

Son zamanlarda Singleton kullanma (ve aşırı kullanma) ile ilgili sorunlar hakkında birçok tartışma yapıldı. Kariyerimde de o insanlardan biriydim. Sorunun şu anda ne olduğunu görebiliyorum ve yine de Nice alternatifini göremediğim birçok vaka var - ve anti-Singleton tartışmalarının çoğu gerçekten bir şey sunmuyor.

İşte katıldığım önemli bir projeden gerçek bir örnek:

Uygulama, çok sık güncellenmeyen bir sunucu durumundan büyük miktarda veri kullanan birçok ayrı ekran ve bileşene sahip kalın bir istemciydi. Bu veriler temelde bir Singleton "yönetici" nesnesinde - korkunç "küresel durum" içinde önbelleğe alındı. Fikir, verilerin depolandığı ve senkronize edildiği uygulamada bu yere sahip olmaktı ve daha sonra açılan yeni ekranlar, sunucudan çeşitli destekleyici veriler için tekrarlayan istekler yapmadan, ihtiyaç duyduklarının çoğunu sorgulayabilir. Sunucuya sürekli istekte bulunmak çok fazla bant genişliği gerektiriyordu ve haftada binlerce dolarlık ilave İnternet faturalarından bahsediyorum, bu yüzden kabul edilemezdi.

Burada bu tür bir küresel veri yöneticisi önbellek nesnesine sahip olmaktan daha uygun olabilecek başka bir yaklaşım var mı? Bu nesne resmi olarak bir "Singleton" olmak zorunda değildir, ancak kavramsal olarak bir olmak mantıklıdır. Burada güzel ve temiz bir alternatif nedir?

570
Bobby Tables

Verdiğiniz durumda, bir Singleton kullanımı sorun değil, bir sorunun belirtisi - daha büyük, mimari bir sorun.

Ekranlar neden önbellek nesnesini veri için sorguluyor? Önbellekleme istemci için şeffaf olmalıdır. Verileri sağlamak için uygun bir soyutlama olmalıdır ve bu soyutlamanın uygulanması önbelleklemeyi kullanabilir.

Sorun büyük olasılıkla sistemin parçaları arasındaki bağımlılıkların doğru şekilde ayarlanmamış olması ve muhtemelen sistemik olması.

Ekranların neden verilerini nereden aldıkları hakkında bilgi sahibi olması gerekiyor? Ekranlara neden veri taleplerini (önbelleğin gizlendiği) karşılayabilecek bir nesne verilmiyor? Çoğu zaman ekran oluşturma sorumluluğu merkezi değildir ve bu nedenle bağımlılıkları enjekte etmenin net bir anlamı yoktur.

Yine büyük ölçekli mimari ve tasarım konularına bakıyoruz.

Ayrıca, bir nesnenin ömür boy değerinin, nesnenin bulunma biçiminden tamamen boşaltılabileceğini anlamak çok önemlidir. kullanın.

Bir önbellek, uygulamanın ömrü boyunca (yararlı olması için) yaşamak zorunda kalacaktır, böylece nesnenin ömrü Singleton'dur.

Ancak Singleton ile ilgili problem (en azından Singleton'un statik bir sınıf/özellik olarak ortak uygulanması), onu kullanan diğer sınıfların onu nasıl bulduğudır.

Statik bir Singleton uygulamasıyla, kural gerektiğinde kullanmaktır. Ancak bu, bağımlılığı tamamen gizler ve iki sınıfı sıkıca çiftler.

Sınıfa sınıfa bağımlılığı sağlarsak, bu bağımlılık açıktır ve tüketen tüm sınıfın bilmesi gereken, kullanabileceği sözleşmedir.

48
quentin-starin

Sadece bu soru üzerine bütün bölüm yazdım. Çoğunlukla oyunlar bağlamında, ancak çoğu oyun dışında uygulanmalıdır.

tl; dr:

Dörtlü Çete deseni iki şey yapar: bir nesneye her yerden kolay erişim sağlar ve yalnızca bir örneğinin oluşturulabilmesini sağlar. Zamanın% 99'u, umursadığınız tek şey bunun ilk yarısı ve ikinci yarısında kartpostal atmak gereksiz bir sınırlama getiriyor.

Sadece bu değil, aynı zamanda rahat erişim için daha iyi çözümler var. Bir nesneyi küresel yapmak, bunu çözmek için nükleer seçenektir ve kapsüllemenizi yok etmeyi kolaylaştırır. Globaller hakkında kötü olan her şey tamamen singletonlar için geçerlidir.

Bunu, aynı nesneye dokunmanız gereken kodda çok fazla yeriniz olduğu için kullanıyorsanız, just bu nesnelere maruz bırakmadan vermenin daha iyi bir yolunu bulmaya çalışın tüm kod tabanı. Diğer çözümler:

  • Tamamen hendek atın. Herhangi bir durumu olmayan ve sadece yardımcı fonksiyonların torbaları olan birçok singleton sınıfı gördüm. Bunların hiç bir örneğe ihtiyacı yok. Onları statik işlevler haline getirin ya da işlevin bağımsız değişken olarak aldığı sınıflardan birine taşıyın. Eğer 123.Abs() yapabilseydiniz özel bir Math sınıfına ihtiyacınız olmazdı.

  • Etrafında dolaşın. Bir yöntemin başka bir nesneye ihtiyacı varsa basit çözüm, onu aktarmaktır. Bazı nesneleri etrafta geçirmekle ilgili bir sorun yoktur.

  • Temel sınıfa koyun. Tümünün belirli bir nesneye erişmesi gereken çok sayıda sınıfınız varsa ve bunlar bir temel sınıfı paylaşıyorsa, o nesneyi tabanda üye yap. İnşa ederken, nesneyi geçirin. Artık türetilmiş nesneler ihtiyaç duyduklarında alabilirler. Korumalı hale getirirseniz, nesnenin hala kapsüllenmiş kalmasını sağlarsınız.

45
munificent

Sorun küresel bir devlet değil.

Gerçekten sadece global mutable state Hakkında endişelenmeniz gerekiyor. Sabit durum yan etkilerden etkilenmez ve bu nedenle sorun daha azdır.

Singleton ile ilgili en büyük endişe, bağlantıyı eklemesi ve böylece test etme gibi şeyleri zorlaştırmasıdır (er). Singleton'u başka bir kaynaktan (örneğin bir fabrika) alarak bağlantıyı azaltabilirsiniz. Bu, kodu belirli bir örnekten ayırmanıza olanak tanır (fabrikaya daha fazla bağlı olmanıza rağmen (ancak en azından fabrika farklı aşamalar için alternatif uygulamalara sahip olabilir)).

Sizin durumunuzda, singletonunuz aslında bir arayüz uyguladığı sürece ondan kurtulabileceğinizi düşünüyorum (böylece başka durumlarda bir alternatif kullanılabilir).

Ancak, tektonlarla bir başka büyük dezavantaj, bir kez yerinde olduktan sonra onları koddan çıkarmak ve başka bir şeyle değiştirmek gerçek bir zor görev haline gelir (yine bu bağlantı vardır).

// Example from 5 minutes (con't be too critical)
class ServerFactory
{
    public:
        // By default return a RealServer
        ServerInterface& getServer();

        // Set a non default server:
        void setServer(ServerInterface& server);
};

class ServerInterface { /* define Interface */ };

class RealServer: public ServerInterface {}; // This is a singleton (potentially)

class TestServer: public ServerInterface {}; // This need not be.
21
Martin York

Sonra ne? Kimse söylemediğinden: Toolbox. global değişkenler istiyorsanız.

Tekil kötüye kullanımdan soruna farklı bir açıdan bakılarak önlenebilir. Bir uygulamanın bir sınıfın yalnızca bir örneğine ihtiyacı olduğunu ve uygulamanın bu sınıfı başlangıçta yapılandırdığını varsayalım: Sınıf tek başına neden tek başına sorumlu olmalıdır? Uygulamanın bu sorumluluğu alması oldukça mantıklı görünmektedir, çünkü uygulama bu tür bir davranış gerektirmektedir. Bileşen değil, uygulama singleton olmalıdır. Uygulama daha sonra bileşenin bir örneğini, uygulamaya özel herhangi bir kodun kullanımına sunar. Bir uygulama bu tür birkaç bileşen kullandığında, bunları bir araç kutusu dediğimiz şeye birleştirebilir.

Basitçe söylemek gerekirse, uygulamanın araç kutusu, kendini yapılandırmaktan veya uygulamanın başlatma mekanizmasının yapılandırmasına izin vermekten sorumlu tek bir düğmedir ...

public class Toolbox {
     private static Toolbox _instance; 

     public static Toolbox Instance {
         get {
             if (_instance == null) {
                 _instance = new Toolbox(); 
             }
             return _instance; 
         }
     }

     protected Toolbox() {
         Initialize(); 
     }

     protected void Initialize() {
         // Your code here
     }

     private MyComponent _myComponent; 

     public MyComponent MyComponent() {
         get {
             return _myComponent(); 
         }
     }
     ... 

     // Optional: standard extension allowing
     // runtime registration of global objects. 
     private Map components; 

     public Object GetComponent (String componentName) {
         return components.Get(componentName); 
     }

     public void RegisterComponent(String componentName, Object component) 
     {
         components.Put(componentName, component); 
     }

     public void DeregisterComponent(String componentName) {
         components.Remove(componentName); 
     }

}

Ama tahmin et ne oldu? Bu bir singleton!

Ve singleton nedir?

Belki de karışıklık burada başlar.

Bana göre, singletonu yalnızca ve her zaman tek bir örneği olması gereken bir nesnedir. Her yere, istediğiniz zaman, anında başlatmaya gerek kalmadan erişebilirsiniz. Bu yüzden static ile çok yakından ilgilidir. Karşılaştırma için, static temelde aynı şeydir, ancak bir örnek değildir. Onu başlatmaya ihtiyacımız yok, hatta yapamayız, çünkü otomajik olarak tahsis edilmiştir. Ve bu sorun yaratabilir ve getirir.

Deneyimlerime göre, Singleton için static yerine basit bir orta boy patchwork çanta projesinde birçok sorunu çözdüm. Bu sadece kötü tasarlanmış projeler için bazı kullanımları olduğu anlamına gelir. Ben tartışmasingleton desenyararlı olup olmadığını düşünüyorum ve gerçekten bad olup olmadığını gerçekten tartışamam. Ama hala statik yöntemler yerine singleton için iyi argümanlar var, genel olarak .

Emin olduğum tek şey singletonlar hakkında kötüdür, iyi uygulamaları göz ardı ederken bunları kullandığımızdır. Bu gerçekten baş edilmesi kolay olmayan bir şey. Ancak kötü uygulamalar herhangi bir kalıba uygulanabilir. Ve biliyorum, bunu söylemek çok genel ... Yani çok fazla var.

Beni yanlış anlamayın!

Basitçe söylemek gerekirse, tıpkı global değişkenler , singletonların yine de her zaman kaçınılmalıdır . Özellikle aşırı istismar edildiği için. Ancak küresel değişkenlerden her zaman kaçınılamaz ve bu son durumda bunları kullanmalıyız.

Her neyse, Araç Kutusu'ndan başka birçok öneri var ve tıpkı araç kutusu gibi, her birinin uygulaması var ...

Diğer alternatifler

  • en iyi makale singletons hakkında az önce okudum önerir Servis Bulucu alternatif olarak. Benim için temelde bir " Statik Araç Kutusu " olacak. Başka bir deyişle, Servis Bulucu'yu bir Singleton yapın ve bir Araç Kutunuz var. Tabii ki, singletondan kaçınma konusundaki ilk önerisine aykırıdır, ancak bu sadece single'ın meselesini kendi başına değil, nasıl kullanıldığıdır.

  • Diğerleri önermek Fabrika Deseni alternatif olarak. Bir meslektaşımdan duyduğum ilk alternatifti ve bunu global var olarak kullanmamız için çabucak ortadan kaldırdık. Elbette kullanımı vardır, ancak singletonlar da öyle.

Yukarıdaki her iki alternatif de iyi alternatiflerdir. Ancak her şey kullanımınıza bağlıdır.

Şimdi, her ne pahasına olursa olsun tektonlardan kaçınmak yanlıştır ...

  • Aaronaught 'ın cevabı hiçbir zaman singleton kullanmamayı önermektedir , bir dizi nedenden dolayı. Ama hepsi, doğrudan desene karşı değil, nasıl kullanıldığına ve kötüye kullanıldığına karşı nedenler. Bu noktalar hakkındaki tüm endişeleri kabul ediyorum, nasıl yapamam? Sadece yanıltıcı olduğunu düşünüyorum.

Soyut ya da alt sınıfa yönelik yetersizlikler gerçekten orada, ama ne olacak? Bunun için değil. arayüz yetersizliği, diyebildiğim kadarıyla . Yüksek bağlantı da orada olabilir, ancak bunun nedeni genellikle yaygın olarak kullanılmasıdır. gerekmez. Aslında, bağlantının kendi içinde tekton deseniyle ilgisi yoktur. Açıklığa kavuşturulmasıyla, test etme zorluğunu da zaten ortadan kaldırıyor. Paralel hale getirme zorluğuna gelince, bu dile ve platforma bağlıdır, bu yüzden, yine desende bir sorun değil.

Pratik örnekler

Sıklıkla 2'nin hem lehte hem de singletonlara karşı kullanıldığını görüyorum. Web önbelleği (benim durumum) ve günlük hizmeti .

Günlüğe kaydetme, bazı tartışacak , mükemmel bir tek örnek, çünkü, ve ben alıntı:

  • İstekte bulunanlar, günlüğe istek göndermek için iyi bilinen bir nesneye ihtiyaç duyar. Bu, küresel bir erişim noktası anlamına gelir.
  • Günlük kaydı hizmeti, birden çok dinleyicinin kaydolabileceği tek bir olay kaynağı olduğundan, yalnızca tek bir örnek olması gerekir.
  • Farklı uygulamalar farklı çıkış cihazlarında oturum açabilse de, dinleyicilerini kaydetme şekilleri her zaman aynıdır. Tüm özelleştirme, dinleyiciler aracılığıyla yapılır. İstemciler, metnin nasıl veya nerede kaydedileceğini bilmeden günlük kaydı isteyebilir. Bu nedenle her uygulama günlük hizmetini aynı şekilde kullanır.
  • Herhangi bir uygulama, günlük kaydı hizmetinin yalnızca bir örneği ile kurtulabilmelidir.
  • Herhangi bir nesne, yeniden kullanılabilir bileşenler de dahil olmak üzere bir günlük kaydı istemcisi olabilir, böylece herhangi bir belirli uygulamaya bağlanmamalıdırlar.

Diğerleri iddia ederken, aslında tek bir örnek olmaması gerektiğini fark ettikten sonra günlük hizmetini genişletmek zorlaşır.

Her iki argümanın da geçerli olduğunu söylüyorum. Buradaki sorun, yine, tekil kalıpta değil. Yeniden düzenleme geçerli bir riskse, mimari kararlar ve ağırlıklandırma üzerinedir. Yeniden düzenleme genellikle gerekli olan son düzeltici önlem olduğunda, başka bir problemdir.

20
cregox

Singleton tasarım modeliyle ilgili temel sorunum, uygulamanız için iyi birim testleri yazmanın çok zor olmasıdır.

Bu "yöneticiye" bağımlı olan her bileşen bunu tekil örneğini sorgulayarak yapar. Ve eğer böyle bir bileşen için bir birim testi yazmak istiyorsanız, bu singleton örneğine veri enjekte etmeniz gerekir, bu kolay olmayabilir.

Öte yandan, "yöneticiniz" bir yapıcı parametresi aracılığıyla bağımlı bileşenlere enjekte edilirse ve bileşen yöneticinin somut türünü, yalnızca yöneticinin uyguladığı bir arabirimi veya soyut temel sınıfı, ardından bir birimi bilmiyorsa test, bağımlılıkları test ederken yöneticinin alternatif uygulamalarını sağlayabilir.

Uygulamanızı oluşturan bileşenleri yapılandırmak ve örneklemek için IOC kapsayıcılar kullanırsanız, IOC kapsayıcısını, "yönetici", aynı, sadece tek bir örnek global uygulama önbelleğini kontrol etmenizi sağlar.

Ancak birim testleri umursamıyorsanız, tek bir tasarım deseni mükemmel olabilir. (ama yine de yapmazdım)

5
Pete

Bir singleton temel bir şekilde değildir kötü, tasarım hesaplamasının herhangi bir şey iyi ya da kötü olabilir. Sadece doğru olabilir (beklenen sonuçları verir) ya da olmayabilir. Kodu daha net veya daha verimli hale getirirse de yararlı olabilir veya olmayabilir.

Tektonların yararlı olduğu bir durum, gerçekten benzersiz bir varlığı temsil etmeleridir. Çoğu ortamda, veritabanları benzersizdir, gerçekten sadece bir veritabanı vardır. Bu veritabanına bağlanmak, özel izinler gerektirmesi veya çeşitli bağlantı türleri arasında geçiş yapması nedeniyle karmaşık olabilir. Bu bağlantıyı bir singletona organize etmek, muhtemelen bu nedenle çok mantıklıdır.

Ancak, singletonun küresel bir değişken değil, gerçekten bir singleton olduğundan da emin olmalısınız. Bu, tek, benzersiz veritabanı gerçekten 4 veritabanı olduğunda, her biri üretim, evreleme, geliştirme ve test armatürleri için önemlidir. Bir Veritabanı Teknesi, bunlardan hangisine bağlanması gerektiğini bulur, söz konusu veritabanı için tek örneği alır, gerekirse bağlar ve arayana geri gönderir.

Bir singleton gerçekten bir singleton olmadığında (çoğu programcı sinirlendiğinde), tembel bir şekilde başlatılan küreseldir, doğru bir örneği enjekte etme fırsatı yoktur.

İyi tasarlanmış bir singleton deseninin bir başka yararlı özelliği, genellikle gözlemlenebilir olmamasıdır. Arayan kişi bir bağlantı ister. Sağlayan hizmet, birleştirilmiş bir nesneyi döndürebilir veya bir sınama gerçekleştiriyorsa, her arayan için yeni bir tane oluşturabilir veya bunun yerine sahte bir nesne sağlayabilir.

Gerçek nesneleri temsil eden tekli desenin kullanılması mükemmel bir şekilde kabul edilebilir. İPhone için yazıyorum ve Cocoa Touch çerçevesinde çok sayıda singleton var. Uygulamanın kendisi UIApplication sınıfının bir tekiliyle temsil edilir. Sadece bir uygulama vardır, bu yüzden bunu bir singleton ile temsil etmek uygundur.

Veri yöneticisi sınıfı olarak bir singleton kullanılması doğru tasarlandığı sürece uygundur. Bir grup veri özelliği varsa, bu küresel kapsamdan daha iyi değildir. Eğer bir dizi alıcı ve ayarlayıcı varsa, bu daha iyi, ama yine de harika değil. Uzaktaki veriler, önbellekleme, kurulum ve sökme de dahil olmak üzere tüm arayüze gerçekten veri yöneten bir sınıfsa ... Bu çok yararlı olabilir.

3
Dan Ray

Singletons sadece servis odaklı bir mimarinin bir programa yansıtılmasıdır.

API, protokol düzeyinde bir singleton örneğidir. Twitter, Google vb.'ye esasen tekil öğelerden erişirsiniz. Peki neden bir programda singletonlar kötüleşiyor?

Bir programı nasıl düşündüğünüze bağlıdır. Bir programı rastgele bağlanan önbelleğe alınmış örneklerden ziyade hizmet toplumu olarak düşünüyorsanız, o zaman tektonlar mükemmel bir anlam ifade eder.

Tektonlar bir servis erişim noktasıdır. Genel olarak, belki de çok karmaşık bir iç mimariyi gizleyen, sıkı sıkıya bağlı bir işlevsellik kütüphanesine arayüz.

Yani fabrikadan farklı bir singleton görmüyorum. Singleton, yapıcı parametrelerini geçirebilir. Örneğin, varsayılan yazıcının olası tüm seçim mekanizmalarına karşı nasıl çözüleceğini bilen bir bağlam tarafından oluşturulabilir. Test için kendi alayınızı ekleyebilirsiniz. Bu yüzden oldukça esnek olabilir.

Çalıştırdığımda ve biraz işlevsellik istediğimde anahtar dahili olarak bir programda. Hizmetin kullanıma hazır ve kullanıma hazır olduğundan güvenle singleton'a erişebilirim. Bu, bir işlemden başlayarak hazır olarak değerlendirilmek üzere bir durum makinesinden geçmesi gereken farklı dişler olduğunda anahtardır.

Genellikle XxxService sınıfının etrafına bir tekli sarma saran bir Xxx sınıfı sararım. Singleton, Xxx sınıfında değil, başka bir sınıfa ayrılmış, XxxService. Bunun nedeni, Xxx olası olmasa da birden fazla örneğe sahip olabilmesidir, ancak yine de her sistemde küresel olarak erişilebilir bir Xxx örneğine sahip olmak istiyoruz. XxxService endişelerin güzel bir şekilde ayrılmasını sağlar. Xxx tek bir politika uygulamak zorunda değildir, ancak gerektiğinde Xxx 'ı tek birton olarak kullanabiliriz.

Gibi bir şey:

//XxxService.h:
/**
 * Provide singleton wrapper for Xxx object. This wrapper
 * can be autogenerated so is not made part of the object.
 */

#include "Xxx/Xxx.h"


class XxxService
{
    public:
    /**
     * Return a Xxx object as a singleton. The double check
     * singleton algorithm is used. A 0 return means there was
     * an error. Developers should use this as the access point to
     * get the Xxx object.
     *
     * <PRE>
     * @@ #include "Xxx/XxxService.h"
     * @@ Xxx* xxx= XxxService::Singleton();
     * <PRE>
     */

     static Xxx*     Singleton();

     private:
         static Mutex  mProtection;
};


//XxxService.cpp:

#include "Xxx/XxxService.h"                   // class implemented
#include "LockGuard.h"     

// CLASS SCOPE
//
Mutex XxxService::mProtection;

Xxx* XxxService::Singleton()
{
    static Xxx* singleton;  // the variable holding the singleton

    // First check to see if the singleton has been created.
    //
    if (singleton == 0)
    {
        // Block all but the first creator.
        //
        LockGuard lock(mProtection);

        // Check again just in case someone had created it
        // while we were blocked.
        //
        if (singleton == 0)
        {
            // Create the singleton Xxx object. It's assigned
            // to a temporary so other accessors don't see
            // the singleton as created before it really is.
            //
            Xxx* inprocess_singleton= new Xxx;

            // Move the singleton to state online so we know that is has
            // been created and it ready for use.
            //
            if (inprocess_singleton->MoveOnline())
            {
                LOG(0, "XxxService:Service: FAIL MoveOnline");
                return 0;
            }

            // Wait until the module says it's in online state.
            //
            if (inprocess_singleton->WaitTil(Module::MODULE_STATE_ONLINE))
            {
                LOG(0, "XxxService:Service: FAIL move to online");
                return 0;
            }

            // The singleton is created successfully so assign it.
            //
            singleton= inprocess_singleton;


        }// still not created
    }// not created

    // Return the created singleton.
    //
    return singleton;

}// Singleton  
3
Todd Hoff

Her ekranın yapıcısında Yöneticiyi almasını sağlayın.

Uygulamanızı başlattığınızda, yöneticinin bir örneğini oluşturur ve iletirsiniz.

Buna Denetimi Ters Çevirme denir ve yapılandırma değiştiğinde ve testlerde denetleyiciyi değiştirmenize olanak tanır. Ayrıca, uygulamanızın birkaç örneğini veya uygulamanızın bazı bölümlerini paralel olarak çalıştırabilirsiniz (test için iyi!). Son olarak yöneticiniz kendi nesnesi (başlangıç ​​sınıfı) ile ölecektir.

Uygulamanızı, yukarıdaki şeylerin altında kullanılan her şeye sahip olduğu bir ağaç gibi yapılandırın. Herkesin herkesi tanıdığı ve küresel yöntemlerle birbirini bulduğu bir ağ gibi bir uygulama uygulamayın.

1

IMO, örneğin iyi görünüyor. Aşağıdaki gibi faktoring dışarı öneririm: her (ve her arkasında) veri nesnesi için önbellek nesnesi; önbellek nesneleri ve db erişimci nesneleri aynı arabirime sahiptir. Bu önbellek kod içinde ve dışında takas yeteneği verir; ayrıca kolay bir genişleme yolu sağlar.

Grafik:

DB
|
DB Accessor for OBJ A
| 
Cache for OBJ A
|
OBJ A Client requesting

DB erişimcisi ve önbellek, aynı nesneyi veya ördek türünü, aynı nesne gibi görünüme devredebilir. Takabileceğiniz/derleyebileceğiniz/test edebildiğiniz ve hala çalıştığı sürece.

Bu, bazı Uber-Cache nesnesini girip değiştirmek zorunda kalmadan yeni önbellekler ekleyebilmeniz için işleri ayrıştırır. YMMV. IANAL. VB.

1
Paul Nathan

İlk soru, uygulamada çok fazla hata buluyor musunuz? belki önbelleği güncellemeyi mi yoksa kötü bir önbelleği mi yoksa değiştirmeyi zor bulmayı mı unuttunuz? (Bir uygulamanın rengi de değiştirmedikçe boyutları değiştirmeyeceğini hatırlıyorum ... ancak rengi geri değiştirebilir ve boyutunu koruyabilirsiniz).

Yapacağınız şey bu sınıfa sahip olmaktır ama TÜM STATİK ÜYELERİ KALDIRIN. Ok bu nessacary değil ama ben tavsiye ederim. Gerçekten sadece normal bir sınıf gibi sınıf başlatmak ve işaretçiyi PASS gibi. Frig etmeyin ClassIWant.APtr (). LetMeChange.ANYTHINGATALL () .andhave_no_structure ()

Daha çok iş ama gerçekten daha az kafa karıştırıcı. Artık küresel olmadığı için değiştiremeyeceğiniz bazı yerler. Tüm yönetici sınıflarım düzenli sınıflardır, sadece böyle davranın.

1
user2528

Partiye biraz geç, ama yine de.

Singleton, her şey gibi bir araç kutusundaki araçtır. Umarım araç kutunuzda tek bir çekiçten daha fazlası vardır.

Bunu düşün:

public void DoSomething()
{
    MySingleton.Instance.Work();
}

vs

public void DoSomething(MySingleton singleton)
{
    singleton.Work();
}
DoSomething(MySingleton.instance);

1. kasa yüksek kuplaj vs yol açar; @Aaronaught anlattığım kadarıyla, açıklamakta sorun yok. Tüm bunları nasıl kullandığınızla ilgili.

1
Evgeni