[Clarence]

Om en klass är beroende av 50 andra klasser så är det dags att refaktorisera den. Men att ett request i slutändan använt 50 klasser är inte så relevant.

Om du tänker dig en Main/applikations-klass och att du sedan går till Controller och sedan en funktionsklass och sedan något annat osv osv... Då kan det var intressant att använda en service-locator med enkel konfiguration istället för att skicka med ett gäng beroende ner i en lång kedja. Målet är inte att hålla sig borta i från service locators utan att skapa så mycket som möjligt i komponenter som inte är beroende av service locatorn. Det som är strikt bundet till just din nuvarande applikation kan vara beroende av en implementation i din applikation..

Om du har en mail-klass så är den kanske beroende av t ex en transport-klass för hur mailen ska skickas och en loggningsklass (som i sin tur är beroende av en handlerklass för hur det ska loggas). Att injicera dessa direkt i mail-klassen gör både att den blir direkt återanvändbar och att det är väldigt enkelt att ändra dessa parametrar i olika driftsmiljöer eller sajter.

Men varifrån dessa hämtas i din applikation spelar mindre roll. Du kan t ex ha en service locator med en konfigurations-service. I din controller eller i en extension av din controller /main-klass kan du hämta den och initialisera Mailer-klassen innan du ska skicka ett mail (och se till att använda delade instanser om du ska göra det fler gånger), det gör i princip att delar av din applikation blir mindre återanvändbar, men det är just sådan kod som är specifik för just din implementation.

Det viktiga är att du försöker identifiera och tänka över de återanvändbara delarna och strukturera dessa med direkt DI. Om en klass har ett specifikt ansvarsområde (SoC - Separation of concerns) blir det ofta lätt att se vilka klasser som går att återanvända. I slutändan bör det mest vara sammanbindande klasser och väldigt specifik funktion som ligger utanför.