Return to Answer

There are three main reasons I can see.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better and also forces you to think about...
2. Modularity. Why should the parser know about the entire list of vehicles and all their properties? It probably doesn't. Maybe it needs to query whether a vehicle id exists or whether vehicle X has property Y. Great, that means you can write a service that does that, and inject only that service into your parser. Suddenly you end up with a design that makes far more sense, with every bit of code only handling data that is relevant to it.
3. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement.

There are three main reasons you should consider.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better and also forces you to think about...
2. Modularity. Why should the parser know about the entire list of vehicles and all their properties? It probably doesn't. Maybe it needs to query whether a vehicle id exists or whether vehicle X has property Y. Great, that means you can write a service that does that, and inject only that service into your parser. Suddenly you end up with a design that makes far more sense, with every bit of code only handling data that is relevant to it. Which leads us to...
3. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement. Again, returning to the parser example, do you really want to always hand-craft an entire list of fully-fledged vehicles for every test case you write for your parser? Or would you just create a mock implementation of the aforementioned service object, returning varying numbers of ids? I know which one I'd choose.

So to sum it up: DI isn't a goal, it's just a tool that makes it possible to achieve a goal. If you misuse it (like it appears you do in your example), you won't get any closer to the goal, there is no magical property of DI that will make a bad design good.

There are two main reasons I can see.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better: why should the parser know about the entire list of vehicles and all their properties? It probably doesn't. Maybe it needs to query whether a vehicle id exists or whether vehicle X has property Y. Great, that means you can write a service that does that, and inject only that service into your parser. Suddenly you end up with a design that makes far more sense, with every bit of code only handling data that is relevant to it.
2. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement.

There are three main reasons I can see.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better and also forces you to think about...
2. Modularity. Why should the parser know about the entire list of vehicles and all their properties? It probably doesn't. Maybe it needs to query whether a vehicle id exists or whether vehicle X has property Y. Great, that means you can write a service that does that, and inject only that service into your parser. Suddenly you end up with a design that makes far more sense, with every bit of code only handling data that is relevant to it.
3. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement.

There are two main reasons I can see.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better.
2. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement.

There are two main reasons I can see.

1. Readability. If every unit of code has everything it needs to work on either injected or passed in as a parameter, it's easy to look at the code and instantly see what it's doing. This gives you a locality of function, which also enables you to separate concerns better: why should the parser know about the entire list of vehicles and all their properties? It probably doesn't. Maybe it needs to query whether a vehicle id exists or whether vehicle X has property Y. Great, that means you can write a service that does that, and inject only that service into your parser. Suddenly you end up with a design that makes far more sense, with every bit of code only handling data that is relevant to it.
2. Testability. For a typical unit test you want to set up your environment for many different scenarios and injection makes this very easy to implement.