Sto osservando un codice legacy in java che utilizza il pattern Locator del servizio come metodo per passare i riferimenti globali invece di passarli più e più volte attraverso gli argomenti del metodo e sto cercando di ridefinire questo approccio. Prima di tutto questo è un buon approccio o indica odore di codice? Se si tratta di odore di codice Il modo migliore per rifattorizzare questo codice è introdurre Iniezione di dipendenza o iniezione del costruttore o iniezione setter?
Sì, molte persone considerano il localizzatore di servizio come un anti-modello. A seconda di come è implementato, può essere difficile il codice di test unitario che lo utilizza, riduce la flessibilità perché i client possono avere solo un'implementazione singola di ogni interfaccia e si affida al test del tipo di runtime in modo che vari errori possano essere rilevati solo a tempo di esecuzione (spesso solo durante l'esecuzione, se i client ritardano l'individuazione dei servizi finché non sono necessari).
L'iniezione di dipendenza tramite parametri del costruttore è la preferenza più comune. Rende le dipendenze di una classe una parte esplicita della sua interfaccia. In un linguaggio tipizzato staticamente, consente al compilatore di verificare che tutte le dipendenze siano soddisfatte (a meno che non si usi un framework che utilizza la reflection, nel qual caso il runtime della lingua lo assicura durante l'inizializzazione del contenitore). E provare in isolamento è banale.
Probabilmente non hai bisogno di un framework DI. Possono risparmiare un po 'di lavoro, ma fare il DI manualmente ti dà il vantaggio del controllo statico del tipo, il che vale la maggior parte del tempo.
Leggi altre domande sui tag anti-patterns refactoring design-patterns service-locator