Thanks a lot for your comment and I agree that that DI containers are useful in many applications such as REST API and so on but they are pretty much not used in game development, at least according my experience about 10 years in this field. It is just seen as 'over-engineering'. Of course I repeat, I am not saying it is bad but the inclusion of an entire framework and methods just to achieve DI is little short of crazy :D, especially it makes developers destroy perfectly clean interfaces just to be able to inject some interchangeable component which will 99.99% of the time never be interchanged.
However, I see many arguments that even if the components will not be interchanged, one must be able to test them in isolation with mock objects and etc. However, I will never buy into the argument that it's worthwhile complicating an interface just to be able to better test it. While testing proves that your tests work, a non-bloated interface is the way forward proving that your code actually works. You would not believe the amount of tests I have seen, just written so that it just passes the test or no errors in unit tests and integration test but the application is full of bugs and crashes.
As a final note, this is just a trivial implementation, in C#, of what we are doing actually in the game and it has been optimized twice already to match our needs. Consider that having 25 manager type classes and each and every Update method will be called 60 times a second, you would not want a framework in your code base where you are not freely alter the logic, especially if you have no control over when to allocate memory
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.
Thanks a lot for your comment and I agree that that DI containers are useful in many applications such as REST API and so on but they are pretty much not used in game development, at least according my experience about 10 years in this field. It is just seen as 'over-engineering'. Of course I repeat, I am not saying it is bad but the inclusion of an entire framework and methods just to achieve DI is little short of crazy :D, especially it makes developers destroy perfectly clean interfaces just to be able to inject some interchangeable component which will 99.99% of the time never be interchanged.
However, I see many arguments that even if the components will not be interchanged, one must be able to test them in isolation with mock objects and etc. However, I will never buy into the argument that it's worthwhile complicating an interface just to be able to better test it. While testing proves that your tests work, a non-bloated interface is the way forward proving that your code
actuallyworks. You would not believe the amount of tests I have seen, just written so that it just passes the test or no errors in unit tests and integration test but the application is full of bugs and crashes.As a final note, this is just a trivial implementation, in C#, of what we are doing actually in the game and it has been optimized twice already to match our needs. Consider that having 25 manager type classes and each and every Update method will be called 60 times a second, you would not want a framework in your code base where you are not freely alter the logic, especially if you have no control over when to allocate memory