A jitter huncutságai
Érdekes és furcsa dolgok történnek néha a .net jitter miatt, ami nem nagyon fordul elő nem managelt környezetben.
Itt ez a kis factoryka részlet:
public IBroker GetBroker()
{
if (broker == null)
{
switch (BrokerMode)
{
case BrokerMode.Simulated:
broker = new BrokerSimulated();
break;
case BrokerMode.IB:
broker = IBBroker.Instance;
break;
}
}
return broker;
}
Amikor meghívtam ezt a sort:
BrokerFactory.Factory.GetBroker().SetInitialEquity(20000);
akkor furcsamód lefutott az élő broker, az IBBroker konstruktora. Pedig NEM az az ág futott le a switchben. Valószínűleg az történt, hogy a jitter hozzáért az IBBroker osztályhoz, ez pedig törvényszerűen kiváltotta a statikus konstruktor lefutását.
A megoldás pofonegyszerű (ha ismerjük az okot :), ki kell emelni a beteg típusra hivatkozást egy külön metódusba. Mivel a jitter metódusonként dolgozik, így addig tényleg nem nyúl a típusunkhoz, míg tényleg nem használjuk:
public IBroker GetBroker()
{
if (broker == null)
{
switch (BrokerMode)
{
case BrokerMode.Simulated:
broker = new BrokerSimulated();
break;
case BrokerMode.IB:
broker = CreateIBBroker();
break;
}
}
return broker;
}
private static IBBroker CreateIBBroker()
{
return IBBroker.Instance;
}
August 4th, 2009 at 2:07 pm
Vagy megjobb megoldas, ha a statikus konstruktorban nem is csinalunk semmit. :)
Tudtommal a statikus konstruktor a tipus inicializalasa soran fut le, azaz akkor, amikor a CLR betolti az adott tipust. Ebben az esetben az adott tipust a fuggveny hivas elott kozvetlenul tolti be (a jitteles kornyeken), hiszen nem tudhatja, hogy az a tipus valoban hasznalva lesz-e a fugveny lefutasa soran, igy kenytelen betolteni az osszes direkt tipushivatkozashoz a hivatkozott tipusokat.
Ezert szokott az lenni a javaslat, hogy statikus konstruktorba csak vegszukseg eseten tagyunk barmit is.
August 4th, 2009 at 2:16 pm
Jogos, csak kényelmes a singletonokat statikus konstruktorból létrehozni. Ebben az esetben nyilván megoldás lehet a kanonikus, lazy initialized singleton is.
August 5th, 2009 at 3:03 am
lehet en vagyok a gyenge, de a “broker” peldany mitol nem null a letrehozastol kezdve?
August 5th, 2009 at 7:26 am
Ez egy factory. A factory arrol ismerszik meg, hogy vagy instancokat gyart, vagy egy darab instance-t ad folyamatosan vissza. Ez esetben ez utobbirol van szo: a rendszer inditasakor a broker termeszetesen null, hiszen senki nem vette a faradsagot erteket adni neki, de ha mar valaki hozzafordult, akkor fogja, es egyszeruen visszadobja a mar letezo peldanyt.
Nyilvan ez egy snippet csak, be kell loni a BrokerMode valtozot (btw, nem a legszerencsesebb egy enumot meg egy valtozot ugyanugy elnevezni), tudni kell, hogy a Factory egy statikus public property, meg ilyenek.
Legalabbis ilyen alapszinten. Google-val nezz utana a factory-knak az sokkal bovebb lere eresztve magyaraz. Azt nem tudom, hogy ez milyen pattern…
August 5th, 2009 at 10:42 am
Ez egy Concrete Factory. A visszaadott productok polimorfak, ezért lehetne abstract factory, de a létrehozó osztályban nincs variáció, így nem az.
A brokernek csak egyszer adok értéket, hisz logikailag az egy singleton, abból csak 1 példány kell a programban, de ennek típusa változó.
Az elnevezésről a következőt írják:
http://msdn.microsoft.com/en-us/library/ab6a8y1b(VS.71).aspx
Parameter Naming Guidelines
“Use type-based parameter names sparingly and only where it is appropriate.”
Én úgy érzetem itt megfelelő. A fw-ben is van számtalan példa erre.
August 31st, 2009 at 6:11 pm
Érdemben sajnos nem tudok a témához szólni, fejvadászként csak felületes ismereteim vannak a .NETről és C#-ból.
Minden elismerésem azoké, aki profi szinten értenek a szakmához ;)
August 31st, 2009 at 6:31 pm
Bezzeg Szilvia: de a spameléshez nagyon értesz. :)
Fennhagyom a linket, mert érdekes lehet valakinek, csak túl átlátszó volt a szándék. :)