"A konstruktor vagy kivételt dob, vagy visszadja az objektumot. Nem adhat vissza null-t. Ez a nyelv specifikációjban benne van."
Igen, ezeket kinyomoztam kozben. Ket jarhato ut van, az egyik a static method elohivas, a masik pedig az IDisposable.
"Szerintem specifikáld pontosabban a problémát, hogy mit szeretnél megoldani.
Megprobalom a rovidebbik valtozatot, mert ha az egesz koncepciot vazolnam fel akkor jovo heten is itt ulnenk. :-) Ezert probaltam fent is tomorebben korbeirni.
Ezt a reszet az algoritmusnak legjobban egy elosztott alkalmazasszerverhez tudnam hasonlitani (nem egeszen az), amely dinamikusan (futas idoben) betoltott modulokat fog futtatni. Az eroforrasok adottak, egy-egy modul betoltodik, megkapja a kert eroforrasokat - ha van ra jogosultsaga - elvegzi a dolgat, majd tavozik, ill tarolja a resultot. Vannak olyan modulok, amelyek orakig is bent csucsulhetnek, dolgoznak, vagy eppen varnak mas modulok vegeztere, de vannak olyanok is amelyek masodpercenkent szazszor is betoltodhetnek (amelyeket nyilvan esszeru cachelni is). A fenti ellenorzes egyszer mindenkeppen le fog futni amikor betoltodik, ill. menet kozben tobbszor is lefuthat elore meghatarozhatatlan alkalommal, a modultol fuggoen. Minden modulban van legalabb egy osztaly amelyik ebbol az osztalybol van leszarmaztatva, mivel a modul az osztott eroforrasokat ezen keresztul eri el.
Tobb oka van amiert a constructor-hackinget probaltam preferalni a fentiekben:
- nehany modul mar meg van irva (akad koztuk olyan is amelyik zart es az API mar adott), ezeknel ki kellene mappelni az uj API-t, ami workaround2 lesz a workaround1-ra + vesztett teljesitmeny...
- szeretem ugy tervezni az API-kat, hogy az kifele transzparens legyen az en belso "nyugjeimtol"
- szeretem ha egy szoftver vilagos, attekintheto, egyseges API-val rendelkezik mindenutt, (lehetosegekhez merten) mert akkor nem kell feltalalni ketszer az orvossagot ugyanazon problemakra :-)
- maximalista vagyok: jobban erdekel az ismeretlen megismerese, mint az elrejtesenek modja :-)
- egyeb okokbol nem tudok aludni, de ha tudnek akkor se tudnek emiatt. :-)
Az IDisposable-tol azert felek, mert ez elore nem volt bekalkulalva, de ha leszarmaztatom ebbol is, halvany fogalmam sincs, hogy milyen biztonsagi/egyeb hibak kerulhetnek elo a kesz modulokban amik tervezes elott nem voltak szamitasba veve. Mindenesetre nem vetettem el teljesen, de tartok tole.
"Szinte biztos, hogy létezik rá bejáratott, szép tervezési minta."
Remelem, hogy igazad van. :-)
Talaltam egyebkent meg mas hasonlo fogos problemat is pl. ami mas nyelvekben szinte de facto szabvanykent van kezelve: a "typedef". Nem lehet forditasi idoben tipusbehelyettesitest vegezni. Futas idoben kiertekeltet lehet, a referencia konyv szeint, ha leszarmaztatom a tipust (ami esetenkent minimalis performancia vesztessel is jarhat). De pl. egy System.UInt16 egyaltalan nem szarmaztathato le, mivel "sealed"-kent van deklaralva (mondjuk tudomanyos alkalmazasokban kulonosen agyrem lehet). Lehet, hogy nincs igazam, de en nem jottem meg ra a megfejtesere ennek sem. :-(
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.