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
Csak én csinálok ebből lelkiismereti kérdést?