it is a good way of not hard-wiring dependencies into parts of the code.
That code should work independently, which makes testing far less complex.
To explain it a bit more:
we want to travel so we take a vehicle to do that.
the vehicle should be able to steer, break and so on.
As a dependency, I give it a car to work with, and the vehicle is now a car and does satisfy its needs, but a plane, a truck, a bike etc. also can do that.
To actually test the software for "the break()" function, you can feed it a mocked-vehicle, that will help you in testing the behaviour. But you can also choose to have a "real" vehicle, up to you.
But if you wrote it by just accepting a car, then that's all it can work with.
SOLID, specifically the "L", implies that a function that requires a "vehicle" must work with cars, bikes, and planes without breaking the application. Dependency injection is not needed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
it is a good way of not hard-wiring dependencies into parts of the code.
That code should work independently, which makes testing far less complex.
To explain it a bit more:
we want to travel so we take a vehicle to do that.
the vehicle should be able to steer, break and so on.
As a dependency, I give it a car to work with, and the vehicle is now a car and does satisfy its needs, but a plane, a truck, a bike etc. also can do that.
To actually test the software for "the break()" function, you can feed it a mocked-vehicle, that will help you in testing the behaviour. But you can also choose to have a "real" vehicle, up to you.
But if you wrote it by just accepting a car, then that's all it can work with.
SOLID, specifically the "L", implies that a function that requires a "vehicle" must work with cars, bikes, and planes without breaking the application. Dependency injection is not needed.