Hej,

Jag har lite funderingar kring användandet av Singleton-designmönstret.

Om man har en eller flera referenser till externa resurser i Singleton-klassen hur bör man lämpligtvis instansiera dessa för att få lazy load.

kodexempel:

using System;

    public class Singleton
    {
        #region Attributes
        private ExternalResource _externalResource;
        #endregion
        
        #region Construction
        private Singleton()
        {
             _externalResource = new ExternalResource();
        }

        public static Singleton GetInstance
        {
            get{ return NestedSingleton.GetInstance; }
        }

        private sealed class NestedSingleton
        {
            private static readonly Singleton _instance;

            static NestedSingleton()
            {
                _instance = new Singleton();
            }

            internal static Singleton GetInstance
            {
                get { return _instance; }
            }
        }
        #endregion

        #region Methods
        public void DoSomething()
        {
            _externalResource.DoSomething();
        }
        #endregion
    }

I exemplet ovan kommer _externalResource att instansieras när man anropar Singleton.GetInstance(), men önskvärt vore om den instansieras när man anropar Singleton.GetInstance().DoSomething().
Skall man implementera externa resurser i singletons som singletons? Detta kanske inte är lämpligt i alla lägen och då kommer jag till frågan om man överhuvudtaget bör ha referenser till externa resurser i singleton-klassen eller om singleton-mönstret är fel mönster i denna situation?

Om jag skall va ärlig var din kod inte direkt sjävlbeskrivande.
Fördel med Patterns är att även förtydliga vad man gör. :-)

I ditt fall förstår jag inte varför du skall ha singleton och jag får inte heller känlsan av att du direkt har lazy load i ditt fall så som lazy load oftast används till.

Lazy Load handlar om att Ladda data typ när man ber om det istället för att det kommer med en gång.
Ex Entitet Order med sina OrderRows.

Det är först när du anropar OrderRows som dessa mappas upp och returneras.
I ditt fall kändes det mer som du skapa en Factory pattern.

Måste du då ens ha Singleton?

Mvh johan

Hej Johan,

Det var det som var frågan:)

Det blir ju inte lazy load i singleton-klassen eftersom ExternalResource-klassen skapas i konstruktorn, och inte när man anropar funktionen i DoSomething, jag skulle vilja veta vart det är lämpligt att skapa instansen _externalResource i detta fall och om det överhuvudtaget är lämpligt i en singleton.

Mvh
Shamanen

För att förtydliga.....

I DoSomething() vill han ha "lazy initialization" av externalResource..... utan att klämma in if som kollar mot null.

Får jag fråga varför du inte vill ha en if-sats i dosomething?


public void DoSomething()
{
EnsureLoaded();
//din kod här..
}

private void EnsureLoaded()
{
if (externalResource == null)
externalResource = ....
}


Är ju det klassiska sättet att lösa LL.

Är det att du inte vill cluttra din kod med den funktionalliteten?
Eller är du rädd för prestandaproblem? (tbh. en nullcheck kommer inte påverka din apps prestanda)

Hej Roger,

Tack för ditt svar.

Anledningen att jag vill komma ifrån if-satsen beror egentligen på implementeringen av singleton-mönstret.
För att få full LL på instansieringen i singleton-klassen skapar man en intern klass, detta gör att man tar bort if-satsen som kontrollerar om instansieringen har skett. Jag skulle vilja veta om det finns ett lämpligt motsvarande sätt för att instansiera externa resurser i singleton-klassen. Om inte så fungerar det att använda sig av if-kontrollen.

Mvh
John

Min åsikt av den implementation av Singleton-pattern som vi ser lite av här och även på (http://en.wikipedia.org/wiki/Singleton_pattern) är att det inte tillför något om man inte har ytterligare static metoder på sin singleton.

Ang. lazy-load i vanlig metod, etc. så är min åsikt att funderar man på lazy-load så är troligtvis kostnaden av en enkel if-sats försumbar.

Annars går det ju alltid att lösa på ett krångligt sätt med delegater ;)