GOF Singleton Pattern'e uygun alternatifler var mı?

Kabul edelim. Singleton Pattern, çitin her iki tarafında ordu programcıları ile oldukça tartışmalı bir konudur . Singleton'ın yüceltilmiş bir küresel değişkenden başka bir şey olmadığını düşünenler ve kalıplara göre yemin edip onu sürekli kullanan başkaları var. Ancak Singleton Tartışmasının sorumun merkezinde yer almasını istemiyorum . Herkes bir halat çekebilir ve onunla savaşabilir ve umursadığım her şey için kimin kazandığını görebilir . Söylemeye çalıştığım, tek bir doğru cevabın olduğuna inanmıyorum ve kasıtlı olarak ateşli partizan çekişmelerini denemiyorum. Soruyu sorduğumda sadece tekil alternatiflerle ilgileniyorum :

GOF Singleton Pattern'e özel alternatifleri var mı?

Örneğin, geçmişte tekil kalıbı kullandığımda çoğu kez, sadece bir veya birkaç değişkenin durumunu / değerlerini korumakla ilgileniyorum. Değişkenlerin durumu / değerleri, bununla birlikte, tekli model kullanmak yerine statik değişkenler kullanılarak sınıfın her bir somutlaştırılması arasında korunabilir .

Başka hangi fikrin var?

DÜZENLEME: Bunun "singleton nasıl doğru kullanılacağı" hakkında başka bir gönderi olmasını gerçekten istemiyorum. Yine, bundan kaçınmanın yollarını arıyorum. Eğlenmek için, tamam mı? Sanırım en iyi film fragman sesinizde tamamen akademik bir soru soruyorum, "Tektonun olmadığı paralel bir evrende ne yapabiliriz?"

" Nefret Ettiğim Örüntüler " de Alex Miller şunlardan alıntı yapıyor:

"Tek bir cevap cevap gibi göründüğünde, genellikle şunu yapmanın daha akıllıca olduğunu düşünüyorum:

1. Bir arayüz ve tekliğinizin varsayılan uygulamasını oluşturun
2. Sisteminizin "tepesinde" varsayılan uygulamanızın tek bir örneğini oluşturun. Bu, bir Spring yapılandırmasında veya kodda olabilir veya sisteminize bağlı olarak çeşitli şekillerde tanımlanabilir.
3. Tek örneği ihtiyaç duyan her bileşene geçirin (bağımlılık ekleme)

Tekilleri geçici olarak çözmenin doğru yolunu anlamak için, Singletons'da neyin yanlış olduğunu (ve genel olarak küresel durumu) anlamanız gerekir:

Singletonlar bağımlılıkları gizler.

Bu neden önemlidir?

Çünkü bağımlılıkları gizlerseniz, birleştirme miktarının izini kaybetme eğiliminde olursunuz.

Bunu tartışabilirsin

void purchaseLaptop(String creditCardNumber, int price){
  CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
  Cart.getInstance().addLaptop();
}

daha basit

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart, 
                    String creditCardNumber, int price){
  creditCardProcessor.debit(creditCardNumber, amount);
  cart.addLaptop();
}

ancak en azından ikinci API, yöntemin ortak çalışanlarının tam olarak ne olduğunu netleştirir.

Bu nedenle, Singletons'a geçici çözüm bulmanın yolu, statik değişkenler veya hizmet konumlandırıcıları kullanmak değil, Singleton sınıflarını, anlamlı oldukları ve bunlara ihtiyaç duyan bileşenlere ve yöntemlere enjekte edilen kapsamda somutlaştırılan örneklere dönüştürmektir. Bunun üstesinden gelmek için bir IoC çerçevesi kullanabilirsiniz veya bunu manuel olarak yapabilirsiniz, ancak önemli olan küresel durumunuzdan kurtulmak ve bağımlılıkları ve işbirliklerini açık hale getirmektir.

Karşılaştığım en iyi çözüm, sınıflarınızın örneklerini oluşturmak için fabrika modelini kullanmaktır. Deseni kullanarak temin edebilirsiniz onu kullanan nesneler arasında paylaşılan bir sınıfın yalnızca bir örneğinin olduğundan .

Yönetmenin karmaşık olacağını düşünmüştüm, ancak bu blog yazısını okuduktan sonra "Tüm Bekarlar Nereye Gitti?"çok doğal görünüyor. Ve bir kenara, birim testlerinizi izole etmenize çok yardımcı olur.

Özetle ne yapmanız gerekiyor? Bir nesne diğerine bağımlı olduğunda, onun bir örneğini yalnızca kurucusu aracılığıyla alır (sınıfınızda yeni anahtar sözcük yoktur).

class NeedyClass {

    private ExSingletonClass exSingleton;

    public NeedyClass(ExSingletonClass exSingleton){
        this.exSingleton = exSingleton;
    }

    // Here goes some code that uses the exSingleton object
}

Ve sonra fabrika.

class FactoryOfNeedy {

    private ExSingletonClass exSingleton;

    public FactoryOfNeedy() {
        this.exSingleton = new ExSingletonClass();
    }

    public NeedyClass buildNeedy() {
        return new NeedyClass(this.exSingleton);
    }
}

Fabrikanızı yalnızca bir kez somutlaştıracağınız için, tek bir exSingleton somutlaştırması olacaktır. BuildNeedy'yi her çağırdığınızda, NeedyClass'ın yeni örneği exSingleton ile paketlenir.

Umarım bu yardımcı olur. Lütfen hataları belirtin.

Spring veya başka herhangi bir IoC-Container bunda oldukça iyi bir iş çıkarır. Sınıflar uygulamanın dışında oluşturulup yönetildiğinden, konteyner basit sınıfları tekil yapabilir ve gerektiğinde bunları enjekte edebilir.

Herhangi bir kalıptan kaçınmak için yolunuzdan çekilmenize gerek yok. Bir desenin kullanımı ya bir tasarım kararı ya da doğal bir uyumdur (sadece yerine oturur). Bir sistem tasarlarken, bir desen kullanma veya kullanmama seçeneğiniz vardır. Ancak, nihayetinde bir tasarım seçimi olan hiçbir şeyden kaçınmak için yolunuzdan çıkmamalısınız.

Singleton Modelinden kaçınmıyorum. Ya uygun ve kullanıyorum ya da uygun değil ve kullanmıyorum. Bunun bu kadar basit olduğuna inanıyorum.

Singleton'ın uygunluğu (veya eksikliği) duruma bağlıdır. Bu, verilmesi gereken bir tasarım kararıdır ve bu kararın sonuçları anlaşılmalıdır (ve belgelenmelidir).

Monostate (Robert C. Martin's Agile Software Development'da açıklanmıştır), singleton'a bir alternatiftir. Bu modelde sınıfın verileri statiktir ancak alıcılar / ayarlayıcılar statik değildir.

Örneğin:

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if(m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate, singleton'a benzer davranışa sahiptir, ancak bunu, programcının bir singleton kullanıldığının farkında olmadığı bir şekilde yapar.

Singleton bir zaman durumlar vardır çünkü modelinin mevcut tek bir nesne hizmetleri kümesi sağlamak için gereklidir .

Durum bu olsa bile, global bir statik alan / özellik kullanarak tekil oluşturma yaklaşımını hala düşünüyorum. , örneği temsil uygunsuz olarak düşünüyorum. Uygun değildir çünkü kodda statik alan ile nesne arasında bir bağımlılık yaratır, nesnenin sağladığı hizmetler değil.

Bu nedenle, klasik, tekli desen yerine, servis verilen konteynerlerde servis 'beğen' modelini kullanmanızı öneririm , burada tekliğinizi statik bir alan üzerinden kullanmak yerine, gerekli servis türünü talep eden bir yöntem aracılığıyla ona bir referans elde edersiniz.

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

tek global yerine

*pseudocode* singletonType.Instance

Bu şekilde, bir nesnenin türünü tekilden başka bir şeye değiştirmek istediğinizde, bunu yapmak için kolay zamanınız olacak. Ayrıca ek bir avantaj olarak, her yönteme nesne örneklerinin ayrılmasını sağlamak zorunda değilsiniz.

Ayrıca Kontrolün Tersine Çevrilmesi konusuna bakın tekilleri doğrudan tüketiciye maruz bırakarak, nesne tarafından sağlanan nesne hizmetleri değil, tüketici ile nesne örneği arasında bir bağımlılık yaratırsınız.

Benim fikrim, mümkün olduğunda tekli modelin kullanımını gizlemek , çünkü ondan kaçınmak her zaman mümkün değildir veya arzu edilmez.

Tek bir veri nesnesini temsil etmek için bir Singleton kullanıyorsanız, bunun yerine bir veri nesnesini bir yöntem parametresi olarak iletebilirsiniz.

(Yine de, bunun bir Singleton kullanmanın ilk etapta yanlış yolu olduğunu iddia ediyorum)

Sorununuz durumu korumak istiyorsanız, bir MumbleManager sınıfı istiyorsunuz. Bir sistemle çalışmaya başlamadan önce, müşteriniz, Mumble'ın sistemin adı olduğu bir MumbleManager oluşturur. Devlet bununla korunur. Muhtemelen MumbleManager'ınız durumunuzu tutan bir eşya çantası içerecektir.

Bu tarz bir stil çok C'ye benziyor ve çok nesne gibi değil - sisteminizi tanımlayan nesnelerin hepsinin aynı MumbleManager'a bir referansı olduğunu göreceksiniz.

Düz bir nesne ve fabrika nesnesi kullanın. Fabrika, örneği ve düz nesne ayrıntılarını yalnızca yapılandırma bilgileri (örneğin içerir) ve davranışla denetlemekten sorumludur.

Aslında Singelton'lardan kaçınmak için sıfırdan tasarlarsanız, statik değişkenler kullanarak Singleton kullanmama konusunda çalışmak zorunda kalmayabilirsiniz. Statik değişkenler kullanırken, aynı zamanda aşağı yukarı bir Singleton oluşturuyorsunuz, tek fark, farklı nesne örnekleri yaratmanızdır, ancak dahili olarak hepsi bir Singleton kullanıyormuş gibi davranır.

Bir Singleton kullandığınız veya şu anda bir Singleton'un kullanıldığı ve onu kullanmaktan kaçınmaya çalıştığınız ayrıntılı bir örnek verebilir misiniz? Bu, insanların durumu bir Singleton olmadan nasıl idare edebilecekleri konusunda daha süslü bir çözüm bulmalarına yardımcı olabilir.

BTW, şahsen Singleton'larla sorunum yok ve diğer insanların Singleton'larla ilgili sorunlarını anlayamıyorum. Onlar hakkında kötü bir şey görmüyorum. Yani, onları kötüye kullanmıyorsanız. Yararlı her teknik kötüye kullanılabilir ve istismar edilirse olumsuz sonuçlara yol açar. Yaygın olarak kötüye kullanılan bir başka teknik kalıtımdır. Yine de kimse mirasın kötü bir şey olduğunu söylemez çünkü bazıları onu korkunç bir şekilde kötüye kullanır.

Şahsen benim için tekil gibi davranan bir şeyi uygulamanın çok daha mantıklı bir yolu tamamen statik sınıf (statik üyeler, statik yöntemler, statik özellikler) kullanmaktır. Çoğu zaman bu şekilde uygularım (kullanıcı açısından herhangi bir davranış farklılığı düşünemiyorum)

Bence singletonu denetlemek için en iyi yer, sınıf tasarım düzeyinde. Bu aşamada, sınıflar arasındaki etkileşimleri haritalandırabilmeli ve kesinlikle, kesinlikle bir şeyin bu sınıfın yalnızca 1 örneğinin uygulama yaşamının herhangi bir anında var olmasını gerektirip gerektirmediğini görmelisiniz.

Eğer durum buysa, o zaman bir singletonunuz var. Kodlama sırasında kolaylık sağlamak için tekli tonlar atıyorsanız, gerçekten tasarımınızı yeniden gözden geçirmeli ve söz konusu tekilleri kodlamayı bırakmalısınız :)

Ve evet, burada "kaçınma" yerine "polis" demek istediğim kelimedir. Tekli kaçınılması gereken bir şey değildir (aynı şekilde, goto ve global değişkenler de kaçınılması gereken bir şey değildir). Bunun yerine, kullanımını izlemeli ve istediğiniz şeyi etkili bir şekilde yapmak için en iyi yöntem olduğundan emin olmalısınız.

Singleton'ı çoğunlukla "yöntem kapsayıcı" olarak kullanıyorum, hiçbir durum olmadan. Bu yöntemleri birçok sınıfla paylaşmam gerekirse ve örnekleme ve başlatma yükünden kaçınmak istersem, bir bağlam / oturum oluşturur ve oradaki tüm sınıfları başlatırım; oturuma atıfta bulunan her şeyin ayrıca içerdiği "singleton" a erişimi vardır.

Yoğun bir şekilde nesne yönelimli bir ortamda (örneğin Java) programlamamış olduğum için, tartışmanın inceliklerini tam olarak bilmiyorum. Ancak PHP 4'te bir singleton uyguladım. Bunu, otomatik olarak başlatılan ve tamamlanmamış ve biraz bozuk bir çerçevede işlev çağrılarının yukarı ve aşağı aktarılması gerekmeyen bir 'kara kutu' veritabanı işleyicisi oluşturmanın bir yolu olarak yaptım.

Tekil kalıpların bazı bağlantılarını okuduktan sonra, onu aynı şekilde tekrar uygulayacağımdan tam olarak emin değilim. Gerçekten ihtiyaç duyulan şey, paylaşılan depolamaya sahip birden çok nesneydi (örneğin, gerçek veritabanı tanıtıcısı) ve bu benim çağrımın dönüştüğü şeydi.

Çoğu desen ve algoritma gibi, tek bir 'sırf havalı olduğu için' kullanmak The Wrong Thing To Do'dur. Bir singleton gibi görünen gerçek bir 'kara kutu' çağrısına ihtiyacım vardı. Ve IMO bu soruyu çözmenin yolu: kalıbın farkında olun, aynı zamanda daha geniş kapsamına ve hangi düzeyde benzersiz olması gerektiğine de bakın.

Ne demek ondan kaçınma tekniklerim nelerdir?

Bundan "kaçınmak" için, bu, tekli modelin doğal olarak uygun olduğu birçok durum olduğunu ve dolayısıyla bu durumları yatıştırmak için bazı önlemler almam gerektiğini ima ediyor.

Ama yok. Tekil kalıbından kaçınmak zorunda değilim. Basitçe ortaya çıkmaz.