No dobra, to na przykladzie:
Wyobraźmy sobie że piszesz klasę odpowiedzialną za zapisywanie plików pewnego typu. Ta klasa zapisuje pliki w podanej lokalizacji ale lokalizacja moze być względna lub bezwzględna. Więc dla ułatwienia sprawy tworzysz nową klasę, która zajmuje się ogarnianiem tych ścieżek, tzn daje ci bezwzględną ścieżkę dla podanej bezwzględnej lub względnej. Jak widać twoja klasa zapisująca pliki potrzebuje tej klasy do działania.
No ale teraz ten nasz ogarniacz ścieżek w rzeczywistości rozpatruje ścieżki względne względem jakiegoś katalogu roboczego zdefiniowanego w konfiguracji aplikacji. Więc potrzebuje do pracy obiektu który daje dostęp do konfiguracji.
Łatwo też zauważyć że w sumie to te obiekty są bezstanowe i wystarczy ci tylko jeden obiekt każdego typu i można z takiego obiekty korzystać z wielu miejsc bez problemów.
Jeśli robisz to za pomocą IoC jak Spring to tworzysz sobie te klasy, oznaczasz jako beany a zależności oznaczasz jako @Inject
i nie zastanawiasz się "skąd" sie bierze taki czy inny obiekt.
W przypadku klasycznym musiałbyś gdzieś sam ręcznie utworzyć tą hierarchie obiektów, rozkminić kolejność tworzenia i odpowiednio poustawiać parametry. Co wiecej jak się nagle okaże że "potrzeba ci jeszcze jakiegoś innego obiektu" to będziesz znowu rozkminiał jak to posortować żeby móc ten obiekt przekazać tam gdzie ci potrzebny.