ugrás a tartalomhoz

DI Container

T.G · 2012. Jún. 8. (P), 07.05
Egy másik fórumtéma kapcsán merült fel bennem a kérdés, hogy konkrétan mit is jelent a „Dependency Injection Container”, mire jó és hogyan kell használni?

Egy minta, ahol gyártófüggvényként lett bemutatva: http://fabien.potencier.org/article/12/do-you-need-a-dependency-injection-container
És egy másik minta, ahol egy asszociatív tömbként: http://pimple.sensiolabs.org

Azért ez a kettő nem egészen ugyanaz, magam részéről a DI-t előszeretettel használom és amikor azt hiszem, hogy DIC-et használok, akkor meg az elsőhöz hasonló szerkezetet, sok „boilerplate kóddal”. :)

Igaz, azt sosem értettem, hogy ezt miért konténernek hívjuk, de valahogy elfogadtam.
Tehát a kérdés: ez csak nekem ellentmondás és tényleg ugyanarról van szó? Vagy az első verzió esetén még nem beszélhetünk DIC-ről, akkor mi az? :)
‹ Php sima form, elakadtam php <?php--?-> ›
 ■
1

Megelőztél :)

eddig bírtam szó nélkül · 2012. Jún. 8. (P), 07.59
Épp most akartam kiemelni egy új szálba a másik topikban a témát. :)

Ami engem nagyon zavar e témában, hogy nem csak itt nem tud megegyezni a társaság, hogy mi is ez, hogyan kell használni stb., hanem úgy általában, netszerte eléggé ellentmondásos, zavaros amit találni lehet róla.

Eddig a legérthetőbbnek tűnő leírás ez volt: http://szjani.hu/blog-entry/read/dependency-injection-es-dic#.Tvw9DAw6hr4.twitter

De van egy olyan kellemetlen érzésem, hogy abban a formában, ahogy nekem javasolták, nem igazán célravezető. Inkább valamiféle keretrendszerben tűnik működőképesnek. Pl. a zend és a symfony tartalmaz olyan alkatrészt (DIC - csak ők nem biztos, hogy így hívják), ami kfejezetten e célra lett kialakítva. (ha jól értettem)
6

Had reagálja a te postodra,

szjanihu · 2012. Jún. 8. (P), 19.23
Had reagálja a te postodra, ha már linkelted az oldalam :)

Mindkét általad említett rendszer legújabb verziója tartalmaz DIC-et. Hogy miért jó?

  • A példányosítást nem kell kódból végezned. Vagyis ha módosul az adott osztály (és vele együtt a konstruktor, mert megváltoztak a függőségei (dependecy!)), elég csak a konfig fájlt szerkesztened
  • Ha egy osztály helyett egy másik osztály példányát akarod használni (és ugye közös az interfészük!), akkor szintén elég csak a konfig fájlt szerkesztened
  • Nem kell globális változókkal, singletonokkal bohóckodni
  • Garantáltan egy objektum jön létre. Nem kell egy már meglévő példány után kutakodni és nem fogsz több felesleges példányt létrehozni

Véleményem szerint nem csak keretrendszerekben van ennek haszna. Ha már van egy adatbázis kapcsolatod, már akkor elgondolkodtató a használata. Nyilván egy kis CLI scriptnél ágyúval verébre lövés.

Ami tényleg fontos: nem minden objektum való DIC-be (hint: service vs. entity típusú objektumok).

Hogy miért konténer? Mert objektumokat tárol és tudja, hogy köztük milyen függőségi viszonyok vannak.
2

Amit én használok

szaky · 2012. Jún. 8. (P), 10.40
Még mielőtt hallottam a DIC-ről, én abstract factory mintát használtam, és environment-nek hívtam :) a lényege az, hogy valahol (elején) legyártottam a környezetet, ami konfigból megkapta a paramétereket, és ezt a env objektumot injektáltam be mindenhova. Ha egy objektum az env-ből lekért valamit, akkor lasy módon szolgálta ki. Szerintem ez viszonylag sok problémára megoldás.
7

Ezzel a megoldással az a baj,

szjanihu · 2012. Jún. 8. (P), 19.43
Ezzel a megoldással az a baj, hogy a minden objektumodnak függősége az environment objektum (service locator). És mivel abból szinte minden más elérhető, ezért soha nem lehetsz biztos abban, hogy egy objektumodnak milyen más függőségei vannak, csak akkor, ha minden egyes alkalommal átnézed a teljes kódját (akármit lekérhet az environmenttől, ugye a függőségi reláció tranzitív). Nehéz tesztelni, nehéz újrafelhasználni.

A legjobb, ha az ember úgy kezd megírni egy osztályt, hogy definiálja a függőségeket és nem foglalkozik azzal, hogy honnan jönnek majd azok.
12

Egyetértek

szaky · 2012. Jún. 9. (Szo), 20.05
Ezzel teljes mértékben egyetértek, mikor ezt megalkottam (mamár máshogy csinálnám), nem is a függőségek kezelésén volt a hangsúly, hanem azon, hogy a: az objektum maga tudja eldönteni (extrém estben futásidőben is) hogy milyen service-kre van szüksége, és b: egy helyen tudjam definiálni, hogy a különböző serviceknek milyen fajtája álljon rendelkezésre (dev env, live env, test env, kiscica env). Szvsz ez nagy alkalmazások kivételével elegendő, a tévedés jogát persze fenntartom.

Ha nagyon erőltetni akarnám a megoldást (amit nem akarok, csak gondolkodom), gyakorlatilag fel kellene ruházni az ENV objektumot, hogy a hívó ismeretében döntsön, mit szolgál ki, és mit nem, és kb megkapjuk az eredeti DIC funkcionalítását. Kíváncsian várom a véleményedet.
3

A DIC lényegét szerintem

Kubi · 2012. Jún. 8. (P), 11.26
A DIC lényegét szerintem Fabien Potencier írta le jobba, olvastam már azt a cikket.

Szerintem akkor kell használni, és ebből jön a lényege is, hogy miért jó, ha egy service-t készítesz (pl.: email küldés), akkor az azt reprezentáló objektumot a DIC-ből kéred ki, ami elintézi neked az inicializálást (vagy új objektumot készít, vagy egy már meglévőt használ, mint singleton, singleton használata ugyebár ronda megoldás lenne :)) és nem kell a kapott objektomról többet tudnod mint az interface-e.

Az előzőből következik, hogy így bármikor lecserélheted a service-t egy másik kóddal, csak az interface-nek kell egyeznie.
4

DIC vs. Service Locator

T.G · 2012. Jún. 8. (P), 14.24
Chris Hartjes: DIC vs. Service Locator Csiripként jött.
5

ZF2 féle

joed · 2012. Jún. 8. (P), 18.48
Valszeg a ZF coding standard miatt, de nekem ZF2 DI megoldása alapján lett teljesen érthető a téma. Erről született egy quickstart quide és egy-két blogbost is. Hátha segít valakinek...
8

Köszönöm!

T.G · 2012. Jún. 8. (P), 20.39
Köszönöm az eddigi hozzászólásokat!
Azért most tényleg sajnálom, hogy nincs itt „tesztik”, „köszönöm”, „+1” gomb vagy valami hasonló!

Ez most nem témalezáró hozzászólás szeretne lenni, csak mivel már annyi (számomra) hasznos infó jött, hogy gondoltam ennek már itt a helye!
9

Amit még mindig nem értek

eddig bírtam szó nélkül · 2012. Jún. 9. (Szo), 10.30
A DI egy tervezési minta, amit ha használni kezdek, akkor az egész alkalmazásomat így illik felépíteni?
Vagy csak egy eszköz, amit akár alkalmazáson belül, több más mintával együtt is használhatok?
Hibának számít-e, ha egyiket sem használom, csak megyek a saját fejem után?

Egyáltalán: mennyire tekinthetők ezek az elvek nyelvspecifikusnak?
Gondolok itt olyasmire, hogy sok helyen kifejezetten java v. c# kötődéssel írnak némely tervezési mintákról. Pl. Python-ban, Ruby-ban mennyire érdemes követni ezeket? (PHP-ben vélek felfedezni némi java kötődést, de pl. a python...)



Tud valaki _egyetlen_ olyan címet mondani, ahonnan elindulhatok a tanulással? Már nincs keretem szakkönyvtár beszerzésére, marad a neten ingyenesen elérhető forrás.
Az eddig megtalált, átnézett anyagokkal az a gondom, hogy specifikus témákról szólnak vagy "alapok" címszóval pár szóban elintézik az egész témát.
10

Minták alatt sokszor objektum

szjanihu · 2012. Jún. 9. (Szo), 12.34
Minták alatt sokszor objektum orientált tervezési mintákat értenek, de ez csak egy része a minták halmazának. A minták bevált módszereket takarnak, ezek a módszerek pedig nem csak objektumok és osztályok kapcsolatára korlátozódhatnak.

Vannak magasabb szintű minták, amik az alkalmazások, vagy azok egy részének a felépítését, működését definiálják. Vannak EAA, deployment minták. Igazából minden probléma, ami eddig felmerült a szoftverfejlesztésben, azokat valahogy megoldották és kialakultak bevett módszerek.

Mint látható, ezek nagy része nem nyelv specifikus. Az OO design patternek is csak az OOP-re építenek, a legtöbb ilyen minta nyelv független. Többféle problémára többféle pattern létezik, hogy mikor melyiket használod, az rajtad múlik.

No meg vannak még a design principles, ezeket is érdemes tanulmányozni.
11

Köszi szépen

eddig bírtam szó nélkül · 2012. Jún. 9. (Szo), 12.59
Úgy látom, itt minden út "Bob bácsihoz" vezet. :-)
13

A Pimple nyomokban sem

tgr · 2012. Jún. 10. (V), 14.41
A Pimple nyomokban sem asszociatív tömb, pont azt csinálja, amit a Symfony DIC (a szerzőjük is ugyanaz egyébként), csak az utóbbi objektumorientáltan, az előbbi meg funkcionálisan lett megvalósítva (és sokkal egyszerűbb, nem kezel pl. XML/YAML konfigurációs fájlokat, hanem sima PHP-ben kell mindent megadni).

A DI lényege az, hogy az osztályod az összes olyan objektumot, amivel együttműködik, kívülről kapja meg, és nem maga példányosítja. Ez az objektumoriántáltság alapelveinek (SOLID) egyikéből következik: minden osztály valamilyen absztrakciónak (interfésznek vagy absztrakt ősosztálynak) egy konkrét implementációja, és egy osztálynak csak a többi osztály által képviselt absztrakcióktól szabad függeni, azok konkrét implementációitól nem. Ez általában úgy van biztosítva, hogy van egy interfész/absztrakt ős, és csak annak a metódusait hívod meg, így a mögöttes implementáció bármikor kicserélhető; nyilván ha az osztályod példányosít egy másik osztályt, akkor ez az elv borul, mert ott lesz az osztályod kódjában a másik osztály neve, vagyis hozzá leszel kötve egy konkrét implementációhoz.

A DI során tehát az osztályod minden olyan objektumot, aminek a függvényeit hívni fogja, kívülről kapja meg, és azok fájdalommentesen kicserélhetőek (ez tipikusan unit teszteknél jön elő, amikor mockolni akarod az éppen nem tesztelt osztályokat). Ez egy összetett rendszerben már elég fájdalmas dolog, ha mondjuk kiderül, hogy egy osztálynak szüksége van valamire, amire eddig nem volt, és öt szint távolságban van a példányosítás helyétől, és az összes szinten át kell adogatni az új osztályt. Ennek az elkerülésére szolgál a DIC, amikor is az összes objektumodat bepakolod egy konténerbe (a gyakorlatban a konténer általában maga végzi a példányosítást, de ez csak implementációs részlet), és az osztályod nem azokat az objektumokat kapja meg, amikre szüksége van, hanem a konténert, és attól lekérheti őket. Ennek vannak hátrányai (egyrészt így eggyel több osztálytól fog függeni, másrészt sokkal nehezebben áttekinthetővé válik a függések rendszere, illetve bárhol hozzáférsz bármihez, míg a sima DI rákényszerít a logikusan elszeparált felépítésre), viszont sokkal egyszerűbbé válik a kód átszervezése.

Úgy is meg lehet fogalmazni, hogy a programodnak van egy kollaborációs gráfja (melyik osztályok melyik más osztályokból hívnak meg függvényeket) meg egy példányosítási gráfja (melyik osztály milyen objektumokat példányosít). Egy naiv programban ez a kettő eléggé hasonló egymáshoz (az osztályok általában maguk példányosítják azokat az objektumokat, amikre szükségük van), és ez ellentmond a single responsibility elvnek: az osztályod a tényleges feladata mellett egy másikat (példányosítás) is végezni kényszerül, és ahogy a példányosítás nemtriviálissá válik (változó konfiguráció, éles és dev környezetek, mockok), ez egyre inkább kezelhetetlenné lesz. A DIC kiszervezi a példányosítás/konfigurációkezelés/környezetkezelés feladatát egy külön osztályba (a sima DI is egyébként, csak ott ez valamelyik legfelső osztály lesz, egy front controller vagy ilyesmi).
14

Amit leírtál...

eddig bírtam szó nélkül · 2012. Jún. 10. (V), 15.27
Abból amit leírtál, számomra az következik, hogy "hivatalosan" nem lehet DI nélküli objektum orientált programot írni, mert az megsérti a S.O.L.I.D. elveit.
Valamint az is, hogy példányosítani tképp csak konténerben szabadna, mert osztályon belül példányosítva sértem a SRP-t.
(konténer nélkül mikor, hol, hogyan lehetne példányosítani?)
15

DI nélkül

janoszen · 2012. Jún. 10. (V), 16.44
DI nélkül lehet, de nem érdemes. Viszont itt a DIC van felvetve, ami azért egy kicsit más tészta. Lehet DI-t C nélkül is csinálni.
18

Lehet

eddig bírtam szó nélkül · 2012. Jún. 10. (V), 19.51
Ha jól értelmeztem az eddigieket, akkor erre is igaz: DI megy DIC nélkül is, de nem érdemes. Pontosabban, ha valami pici dolgot készítek, akkor a DI is felesleges. Ha valami nagyméretűt, akkor meg Controller nélkül inkább bele se kezdjek.
Rosszul értelmezem?
21

DIC

janoszen · 2012. Jún. 11. (H), 02.08
Én nagy dolgoknál sem szeretem a DIC-et, mert mint már említettem, megöli a kódkiegészítést és/vagy sok boilerplate kódot eredményez. Ezen felül engem zavar, hogy kb. minden függ tőle és ezen felül a string paraméterezés miatt nehezen debuggolható. Maradjunk annyiban, hogy láttam én már DIC nélkül szép nagy projekteket és működtek, valamint DIC-el szép nagy projekteket, amik nem működtek.
22

Nyilván egy projekt sikere

inf · 2012. Jún. 11. (H), 02.44
Nyilván egy projekt sikere nem azon múlik, hogy használsz e DIC-et, vagy sem...
23

A DIC egy-egy meghívása elé

tgr · 2012. Jún. 11. (H), 07.05
A DIC egy-egy meghívása elé beírni, hogy /** @var SomeClass */, pont ugyanannyiba kerül, mintha lenne a konstruktornak egy extra paramétere, és ahhoz írnál PHPdocot, úgyhogy ez a kódkiegészítéses dolog nekem nem hangzik meggyőzően. A string paraméterezést meg semmibe se kerül átalakítani __call-á, ha az jobban tetszik, bár nem értem, miért befolyásolná a debuggolhatóságot. Az tény, hogy szorosabban csatolt lesz tőle a kód, mert minden osztályod függ a konténertől - a gyakorlatban azért egy DIC elég egyszerű ahhoz, hogy sose kelljen visszafelé nem kompatibilis változtatásokat végezni rajta (de ha mégis, az nagy szívás). DIC nélkül viszont az a nagy szívás, ha át kell szervezni a programot, és jelentősen megváltoznak a függőségek, és minden X idejű átíráshoz 3X ideig kell javítgatni a függőségek közvetítését.

Maradjunk annyiban, hogy láttam én már DIC nélkül szép nagy projekteket és működtek, valamint DIC-el szép nagy projekteket, amik nem működtek.


C-ben is írtak jól működő nagy projekteket... az, hogy milyen tervezési mintákat használsz, sokadlagos tényező a sikerességben ahhoz képest, hogy mennyire átgondolt és jól szervezett a kód, mennyire lettek jól felmérve a követelmények stb. Nem akarok úgy csinálni, mintha hű de nagy tapasztalatom lenne a témában; mindenesetre én az utolsó projektemnél nem használtam DIC-t (én is a túl központosított függőségek miatt idegenkedtem tőle), és sokat szívtam miatta. (Ami persze nem zárja ki, hogy ha használok, akkor más miatt szívtam volna, de ha újra kéne kezdenem, DIC-vel csinálnám.)
24

Kódkiegészítés

eddig bírtam szó nélkül · 2012. Jún. 11. (H), 08.18
(elnézést, csak előszedtem a kukából a múltkori kódomat, ezért nincsenek átírva az általatok javasoltnak megfelelően a nevek)

Szóval csináltam egy ilyet:

class ParametersFromFile { ... }
class IniParser { ... }

class DIC {
    protected static $classes=array();
    
    function __construct() {
        $classes["ParametersFromFile"]=new ParametersFromFile();
        $classes["IniParser"]=new IniParser(self::getClass("ParametersFromFile"));
    }
    static function getClass($className){
        return self::$classes[$className];
    }
}

/** @var IniParser */
$inip=DIC::getClass("IniParser");
Hogy logikailag milyen, abba most ne menjünk bele, de ugye kb. erről lenne szó? Vagy valamit rosszul használtam? Ugyanis a NetBeans kódkiegészítője nem hajlandó ebben a formában együttműködni vele. (PHP-hez eddig ez tűnt a leghasználhatóbbnak)
Vagy szokás szerint félreértek valamit?
28

Azt hiszem, a

tgr · 2012. Jún. 11. (H), 22.38
Azt hiszem, a NetBeans/Eclipse PDT szintaxis valami ilyesmi:

/* @var $inip IniParser */
$inip=DIC::getClass("IniParser");
32

Szóval félreértettem

eddig bírtam szó nélkül · 2012. Jún. 12. (K), 06.57
A hozzászólásod alapján arra gondoltam, a PHPdoc szintaxist kellene használnia azoknak az IDE-knek, amelyek támogatják az ilyesmit.
(és hát igen, amit janoszen lentebb írt, abban is van valami)
33

Azt kéne használniuk, de nem

tgr · 2012. Jún. 12. (K), 07.59
Azt kéne használniuk, de nem azt használják :)
Nem tudom, miért döntött a NetBeans (ill. az Eclipse, amiből ők átvették) éppen e mellett a szintaxis mellett.
25

Pont ez a baj

janoszen · 2012. Jún. 11. (H), 08.48
Na ez meg a másik, hogy tudnod kell, mi jön ki az adott DIC hívásból. Ha nem tudod, túrhatod a configot, ami megtöri a gondolatmenetedet.
29

Hát ha a visszaadandó

tgr · 2012. Jún. 11. (H), 22.42
Hát ha a visszaadandó osztály(ős) nevét használod függvénynévnek/paraméternek, akkor nyilván tudod. Ha meg bevezetsz egy osztálynevektől teljesen független szolgáltatásnevet, az egy plusz feature, amit feltehetőleg azért használsz, mert valami olyan előnyt nyújt, ami meghaladja a nehezebb követhetőség okozta hátrányt. A DIC pedig (szemben a sima DI-vel) lehetővé teszi, hogy használd.
30

Fejben

janoszen · 2012. Jún. 11. (H), 22.47
Az ember feje nem káptalan. Nagyobb projekteknél sem a string nevére, sem az osztályra nem emlékszel, ilyenkor jönne jól a ködkiegészítés, ami nincs.
34

Az IDE nem írja meg helyetted

tgr · 2012. Jún. 12. (K), 08.02
Az IDE nem írja meg helyetted a programot, akkor se, ha nem használsz DIC-t... valahogy csak ki kell találnod, milyen függőségei vannak az aktuális osztálynak, ha sima DI-t használsz, akkor a konstruktor vagy a megfelelő setter írásakor, ha DIC-t, akkor meg valamikor máskor. A kódkiegészítés egyik esetben sem segít.
27

Nem akarok úgy csinálni,

inf · 2012. Jún. 11. (H), 19.38
Nem akarok úgy csinálni, mintha hű de nagy tapasztalatom lenne a témában; mindenesetre én az utolsó projektemnél nem használtam DIC-t (én is a túl központosított függőségek miatt idegenkedtem tőle), és sokat szívtam miatta.


Nekem van olyan ismerősöm, akinek hú de nagy tapasztalata van a témában, multi cégnél dolgozik, azt hiszem középvezető beosztásban (felügyel 20+ emberre). Megkérdeztem, azt mondta neki sem indul egy projektnek unit test-ek és DIC nélkül. Persze ez is olyan dolog, mint hogy valaki inkább notepad-ben szerkeszt, mert nem kell neki IDE. Embere válogatja... :-)
26

Ezen felül engem zavar, hogy

szjanihu · 2012. Jún. 11. (H), 14.38
Ezen felül engem zavar, hogy kb. minden függ tőle


Alig pár objektumnak szabad csak lennie, ami közvetlenül a DIC-et használja. Mondjuk egy ZF-es alkalmazásnál a bootstrap folyamán a DIC-ből szedem ki a pluginokat és regisztrálom be őket (technológiai problémák miatt, normális keretrendszer esetén erre nem lenne szükség), valamint a controllerekben használom. Ennyi, sehol máshol.
16

Objektumorientált programot

tgr · 2012. Jún. 10. (V), 18.38
Objektumorientált programot nem azért ír az ember, mert ha a Paradigma-Ellenőrző Bizottság elismeri SOLID-kompatibilisnek, akkor leírhatod az adóból... ha kicsi programot írsz, és nem tudnád kihasználni egy OOP eszköz nyújtotta előnyöket, akkor felesleges vesződni vele. DI-re tipikusan akkor van szükség, ha az adott osztályt unittesztelni akarod (általában mindent akarsz, ha fennáll az esélye, hogy az adott kódhoz a jövőben még hozzá kell nyúlni, de pl. valami egyszerhasználatos migrációs scriptnél vagy kampányoldalnál lehet, hogy nem akarsz vesződni vele).

Konténer nélkül tipikusan a rendszer indításakor indítasz, a legelsőként lefutó osztályban, ami beolvassa a konfigurációs fájlokat, és létrehozza a tényleges vezérlő objektumot. MVC-s, routingos webalkalmazásnál ez a front controller, vagyis az a fájl, ami elkapja az összes requestet.
17

P.E.B :-)

eddig bírtam szó nélkül · 2012. Jún. 10. (V), 19.49
"Paradigma-Ellenőrző Bizottság"
Hát igen, pedig ilyesmire gondoltam, ha nem is ezen a néven. :-)
Inkább úgy fogalmaznék, hogy ha vannak olyan elmebeteg álmaim, hogy majdan ebből éljek és netán valahol foglalkoztatnának egy kezdő, de OOP-t használni tudó egyént, akkor foglalkoznak-e az illető jelentkezésével amennyiben nem követi pontról pontra a SOLID elveit?
19

Hát, szerintem az esetek nagy

tgr · 2012. Jún. 10. (V), 23.57
Hát, szerintem az esetek nagy részében neked kell majd elmagyaráznod a felvételiztetőnek, hogy mik azok...
20

A DI lényege az, hogy az

inf · 2012. Jún. 11. (H), 02.05
A DI lényege az, hogy az osztályod az összes olyan objektumot, amivel együttműködik, kívülről kapja meg, és nem maga példányosítja. Ez az objektumoriántáltság alapelveinek (SOLID) egyikéből következik: minden osztály valamilyen absztrakciónak (interfésznek vagy absztrakt ősosztálynak) egy konkrét implementációja, és egy osztálynak csak a többi osztály által képviselt absztrakcióktól szabad függeni, azok konkrét implementációitól nem. Ez általában úgy van biztosítva, hogy van egy interfész/absztrakt ős, és csak annak a metódusait hívod meg, így a mögöttes implementáció bármikor kicserélhető; nyilván ha az osztályod példányosít egy másik osztályt, akkor ez az elv borul, mert ott lesz az osztályod kódjában a másik osztály neve, vagyis hozzá leszel kötve egy konkrét implementációhoz.


Na ez a lényeg :-) Olyan szépen megfogalmaztad, hogy lehet, hogy idézni foglak :D


Ennek az elkerülésére szolgál a DIC, amikor is az összes objektumodat bepakolod egy konténerbe (a gyakorlatban a konténer általában maga végzi a példányosítást, de ez csak implementációs részlet), és az osztályod nem azokat az objektumokat kapja meg, amikre szüksége van, hanem a konténert, és attól lekérheti őket.


A DIC-eknél szerintem ugyanúgy meg kell jelennie egy példányosítási gráfnak, ha mindent egyetlen DIC-ben tárolsz az god object anti pattern.
31

A DIC másra is jó. :-)Egy

inf · 2012. Jún. 12. (K), 04.26
A DIC másra is jó. :-)

Egy átlagos osztály viselkedése körülbelül így néz ki:
  1. Példányosítás.
  2. Konfigurációs paraméterek megadása.
  3. Konfigurálás, ha megvan minden paraméter.
  4. Bemeneti paraméterek megadása.
  5. Feldolgozás, ha megvan minden paraméter.
  6. Kimeneti paraméterek olvasása.

Na most én állandóan abba a problémába ütközöm, hogy elfelejtem lefuttatni a konfigurálást. Ezért általában valamelyik "egyezményes" setter-be teszem, hogy hívja meg automatikusan. A DIC-vel ezt ki lehet váltani, mert annak direkt az a feladata, hogy az első 3 pontot teljesítse újrafelhasználható módon...