Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.

February 3, 2014 / by Zsolt Soczó

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?

Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.

LEAVE A COMMENT

13 COMMENTS

  • Harasoft February 3, 2014

    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.

  • Soczó Zsolt February 7, 2014

    A facebookon megmondták a jelenleg elfogadott megoldást a témára:
    https://www.facebook.com/zsolt.soczo
    (Nem tudom, hogy tudok direkt linket írni egy bejegyzéshez).

  • Tamás February 9, 2014

    A post dátumánál éred el a direkt linket.

  • Soczó Zsolt February 10, 2014
  • teszekrá February 11, 2014

    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).

  • Soczó Zsolt February 13, 2014

    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.

  • teszekrá February 17, 2014

    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?

  • Soczó Zsolt February 19, 2014

    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.

  • teszekrá February 19, 2014
  • teszekrá February 19, 2014

    Grétsy László:

    https://hu-hu.facebook.com/NapiHelyesirasiSzosszenetek/posts/197739907076179

    Az érdekes lesz majd, amikor a gyerekem azt fogja írni a kis dolgozataiban, hogy eszek, iszok, alszok. Majd azt fogja mondani a tanárnéninek, hogy Apa meg Anya így tanította, mert így a _normális_! :)

    (Poénos az lesz majd, hogy a tanítónéni tudni fogja, hogy Anya is tanítónéni.)

  • Soczó Zsolt February 19, 2014

    Hm, akkor most törekszek rá vagy törekszem rá? Mi a mai módi?

  • teszekrá February 19, 2014

    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 :).

  • teszekrá February 20, 2014

    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ő.