[mjr00]

> In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. ... For example I can exchange the DI framework for the whole project in a matter of days if need be.

Game engines aside, this is a very late 90s/early 00s philosophy that has really not stood the test of time. The code that strictly follows this principle ends up looking like Enterprise FizzBuzz[0]. Trying to do this results usually in a lot of time spent building an abstraction layer around one thing, and that one thing not actually being replaceable because it was only ever built or tested with that one thing, so trying to replace Thing One with Thing Two is even more work as you now have to rip out both Thing One and adjust or remove the abstraction layer around it.

Abstractions aren't free, and the more complex the library you're trying to abstract, the more expensive they are.

There's nuances to this of course -- it's a lot easier to write a custom wrapper around a logging library than a DI framework, for example. But in general if you're using a third party library, things end up cleaner if you just commit to it rather than write an abstraction layer.

[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...