Maybe this says more about the quality of the code I have to work on or my own lack of ability.
Our legacy code often comes along with a large number of interfaces and dependency injection and it's difficult to find where the code actually 'does something'. So the only way I can understand what the code is doing is by stepping through it in a debugger.
If I just try to read it, I end up half a dozen classes away from the method I'm trying to understand in no time.
> So the only way I can understand what the code is doing is by stepping through it in a debugger.
If methods are factored and named well, the name tells you what it does and you shouldn't have to look at the implementation unless its not doing what it says.
I've found that good OO programs are understood by understanding the classes and messages between them, not by reading the implementations of those methods. Look for the big picture, not the details.
I've been working with Zend Framework 2 (PHP) and it has a ServiceManager class that loads everything, but the configurations can be done in three different ways and it supports aliases and other things that make it really freaking hard to find out where a class came from. It's a huge learning curve. I understand using DI to make code testable but it also seems to make it a lot harder to follow.
Sounds like you encountered what I call an "Uh-O Architecture". It's basically OO but overdone. Too many classes, too fine-grained, too abstract, too many layers, too many designer patterns for the sake of design patterns, etc.
Our legacy code often comes along with a large number of interfaces and dependency injection and it's difficult to find where the code actually 'does something'. So the only way I can understand what the code is doing is by stepping through it in a debugger.
If I just try to read it, I end up half a dozen classes away from the method I'm trying to understand in no time.