Weblabor

Mivel mostanság egyre többször előjönnek a DI, Singleton, Multiton, Unit Testing, TDD stb. buzzwordok és társaik kérdés, és ismerősök is egyre többször kérdezgetnek ez ügyben, gondoltam feldobok egy újabb témát vitaindító jelleggel.

Hogy miért? Nagyon jól tudjuk, hogy mik az előnyei a mindenféle „csudabuzzword” által takart megoldásoknak… Leginkább, ha az ember nagy projektet fejleszt. Nos, ezzel a problémám az, hogy a legtöbb projekt nem ilyen. Nagyon nem ilyen.

Éppen ezért nem értem, hogy mi ez az architektúrális felhőkarcoló gyártás, ami mostanság divatként terjed. DI nagyon jól megold néhány problémát. Egyetlen bajom vele, hogy ugyan betartat dolgokat, csak épp plusz kódmennyiséggel. Emiatt sokszor inkább úgy érzem a hasonló dolgokkal, hogy mert ez a divatos és szép ezért beleerőltetjük mindenhova, ahelyett, hogy egy percre megállnánk és elgondolkodnánk, hogy kell-e ez most egyáltalán nekünk.

Hogy megértsétek, mire gondolok, induljunk ki az alapoktól. Adott egy megrendelés. Feltesszük a bűvös varázskérdéseinket, hogy tulajdonképp mi a fenét is kell nekünk elkészítenünk. Egyszerűség kedvéért legyen most ez egy egyszerű weblap, néhány hírrel meg pár termékoldallal és egy kapcsolatfelvételi űrlappal. Rutinmeló, egy délután alatt össze lehet ütni. Nulláról.

Hogyan is fog ez lefutni? Beesik a kérés a webszerverre, elindul a rendszerünk, csinálunk egy sablon rendszert, egy SQL réteget, esetleg valamilyen user kezelő megoldást, amit majd birizgálni fognak a moduljaink. Majd miután lefutott a modulunk, jól megjelenítjük a tartalmakat a látogatónak. (Tfh. most megállunk a hasonló komplexitású rendszereknél.)

Erről a rendszerről mit tudunk? Van egy egyszerű keretrendszerünk és néhány egyszerű modulunk, ami feltételezi, hogy ők valahogyan tudnak birizgálni SQL réteget, sablon rendszert és egy bejelentkezett felhasználót. (Most ne menjünk el, hogy ez MVC vagy nem MVC rendszer, irreleváns).

Tapasztalataim szerint ennél jóval bonyolultabb (keret)rendszer átfogó design dokumentációja is elfér n*10 oldalon, amiben le van írva egyszerű példákkal ábrázolva, hogy azt hogyan is kell használni egy ilyen egyszerűé meg végképp elfér 5 oldalon.

Ezek után nem értem, hogy miért jó nekem az, hogy plusz kódokat írogassak ugyanazért a funkcionalitásért, hogy elérjek bizonyos alrendszereket. Ez egy weblap. Elindul, létrehozza a szükséges dolgokat, amik általában kellenek (és általában tényleg mind kell), csinál valamit a rendszer, majd befejezi a dolgát. Szerintem ilyen esetekben kár nehezíteni az életünket, hogy külön figyelgessük, hogy most ide ez meg az meg amaz kell. Része az alaprendszernek, jöjjön létre az inicializálás során és kész.

Ilyen esetre szerintem (majdnem) teljesen ugyanolyan jó, akár Singleton, akár egy homlokzat mintát akár globális változót használunk. (Bár a Singletonnal konkrétan itt annyi talán a bajom az Unit Testingen kívül, hogy felesleges a lazzy load, mert nagy valószínűséggel úgy is kelleni fog. -- megjegyzem sok ilyen kaliberű esetben ez se játszik.

Anno, mikor a mostani rendszereink végső alapját kialakítottuk (a korábbi munkák összegzése után kezdtük el fejleszteni) nálunk is szóba került a Singleton és a homlokzat. (DI akkor még nem nagyon volt benn a köztudatban, magam sem ismertem akkor konkrétan így). Végső döntés az volt, hogy marad a globális változó. Egyrészt, mert egyszerű, nem okoz szerializálási problémákat (pl. ha egy objektum adattagjaként beemeljük) másrészt azt a kb. 7-8 változót nem lehetetlen megjegyezni (mindenki tudja, hogy ezek azok, elég egyértelműek, doksiba le van írva és amúgy is, nem kezdünk el úgy egy rendszert fejleszteni, hogy picit se nézzük meg mi merre hány méter) és nem igényel plusz függvényhívást sem. Lehet mondani, hogy csúnya gonosz global, de attol még gyors, egyszerű és működik. Jól. És még csak véletlenül sem történt olyan, hogy valaki felülcsapott valamit.

Ráadásul szerintem unit testingnek sem mond ellen. Meg lehet adni teszt előtt/utáni eseményeket, ott meg meg lehet oldani, hogy hozza létre ezeket újra, vagy inicializálja újra a keretrendszert.

Természetesen nem vagyok a DI ellen. Csak nem látom indokoltnak minden esetben.

Vagy hozhatnék még egy példát: egy barátommal is épp beszélek Skypen, épp a Symfony2-s FileResource osztályról elmélkedünk. Véleményem szerint ezek az osztályok is indokolhatóak. Csak sokszor a feladat nem indokolja.