Service locator pattern design kérdés

Sokak szerint Service Locator pattern antipattern.
Ok, ha egy ezer soros osztályban (ez már önmagában code smell) tucatnyi metódusban el vannak dugva service locator hívások, akkor a kódot olvasva nehéz meghatározni, milyen függőségei vannak, így nehéz tesztelni is (tudjuk, a kódot embereknek írjuk, nem a compilernek, az megérti a dzsuvát is). Ebben a helyzetben a konstruktor injectionnel nyilvánvalóan be lehet küldeni a függőségeket, az osztály elejét elolvasta azonnal szembeötlik, miket kell kifakelni, ha tesztelni akarjuk.
Na, de mi van a facade vagy controller jellegű osztályokkal? Ezek sok tucatnyi más osztállyal működnek együtt, pont ez a feladatuk, hogy a külvilágnak ne kelljen a belső részleteteket megérteni. Az ilyen osztályoknak tucatnyi függősége van, amelyeket viszont -szerintem- értelmetlen lenne konstrukciós időben létrehozni, főleg, ha jelentős részét nem is fogják használni a közeljövőben. Ilyenkor tudomásom szerint nem nagyon marad más, mint hogy a hívott metódusokban service locatorral létrehozni a függőséget, és belehívni.
Mindezt csak azért vetem fel, mert rossz érzésem van, amikor leírom egy kódban, hogy Di.Resolve(), de az előbbi érvelés alapján meg tudom indokolni, mikor mégis csak jogos a service locator.
Csak én csinálok ebből lelkiismereti kérdést?

13 thoughts on “Service locator pattern design kérdés

  1. Harasoft

    Szia Soci!

    Valahol lennie kell a végpontnak, ahol már nem tudod tovább halogatni a konkrét típusok létrehozását! :) Viszont mivel a Facade-ban elvileg csak BL áthívás lehet és annak a konstruktorában adod át a konkrét típust, ott nem tudod elkerülni de nem is kell, mert nincs is mit tesztelni, nincs semmilyen megvalósított algoritmus. És szerintem ott nem baj, ha ServiceLocator-al kreálod a konkrét típust, de konkrét típus létrehozása se.

    Ha Controller pattern esetében MVC-ről beszélünk az tud konstruktor dep injection-t, ott nem kérdés, tesztelhető is marad.

  2. teszekrá

    Szerintem nem hatékony, ha egy programozó állandóan azon görcsöl, hogy “mit fog szólni ehhez valaki”.

    GOTO, BREAK, CONTINUE.
    Akadémia? Leszarom.

    Hatékonyság?
    Csak ez számít.
    Nem vagyunk egyformák (a hatékonyság mindenkinél másként van jelen).

  3. Soczó Zsolt Post author

    teszekrá: vannak design elvek, amelyeket ha megsértünk nagyon visszaütnek, ha nagy kódról van szó, amit sokan szerkesztenek. Iszonyatosan átláthatatlan turha lesz a kódból sok esetben, ezért törekszek rá, hogy ha másoknak volt problémája valamivel, azt ne ismételjem meg.
    A legjobb próba erre, hogy gyomorgörcsöd van-e, ha hozzá kell látni a kolléga vagy saját kód módosításához? Ha igen, akkor valószínűleg nem ok vele, nem lehet jól átlátni.

  4. teszekrá

    Végre egy kolléga, aki nem követi az ikes igék ragozásának szabályát.

    Amúgy véletlen vagy tudatos?

  5. Soczó Zsolt Post author

    teszekrá: mit nem követek? Tényleg érdekel, mindig is érdekelt a helyesírás, főleg, hogy kisfiam felvételizik, de nem értem, mire hivatkozol a szövegben.

  6. teszekrá

    Pont ezzel kezdtem a posztolásom, hogy lényegtelen, hogy mi a módi.

    Én azért eszek, meg iszok, mert ez a természetes ragozása az ikes igéknek; az, hogy valami szerencsétlen valamikor régen kitalálta, hogy attól lesz igazán művelt meg választékos a “felsőbb osztály” beszéde, ha elhagyják az ikes igék esetén az alanyi ragozást, nem érdekel.

    Nyilván én is a szabályzat szerint tanultam meg gyerekkoromban, de felnőttként egyszer felfedeztem, hogy ez egy baromság; onnantól nem használom, tehát onnantól eszek, iszok, alszok, és ami a legnagyobb poén számomra, ha egyszer-egyszer eltévesztem társaságban, pl. azt mondom, hogy iszom, akkor azonnal kijavítom, hogy iszok. Ilyenkor szoktam figyelni a reakciókat, de eddig még senki sem kérdezett meg, hogy miért javítottam ki magam. Ha megkérdezne, akkor azonnal megadnám neki a lezos linket.

    “… Kevesen veszik tudomásul, hogy az “ikes ragozás, mint rendszer, nem él” (lásd: Nyelvművelő kézikönyv, továbbá Grétsy László kijelentését: “Az ikes ragozásról már fél évszázada tudjuk, hogy halálra van ítélve. Lőrincze Lajos, jeles elődöm már 1953-ban megírta Ikes ige – ikes iga című nevezetes cikkét. …”

    Amúgy nem tudom miért van, de kifejezetten jó érzés, hogy a sok iszomozó meg eszemező közt én iszok meg eszek; és a párom is iszik meg eszik, pedig tanár, nem falun :).

  7. teszekrá

    Egy picit a témához is kapcsolódóan:

    “Design Patterns: Making C++ suck less”

    Szerintem a sok dizájnpetörn helyett jobb választás valami jobb kódolásra szánt nyelv, valami dinamikus ketyere.

    Groovy; ha már a Java mindenütt elérhető.

Comments are closed.