Even though I prefer the DI style, I don't think DI is an option for an API (unless the API is some sort of runtime container).
An API is usually called by the user, while the DI framework calls the user classes.
Turning it the other way around and enforcing your DI impl on the user hurts in many ways.
Also using an injectable singleton the code stays slightly cleaner, since you can keep it's reference in any scope, while DI always makes everything a member variable (unless you perform work in a setter or constructor, which is against convention or complicates testing).
Follow
Even though I prefer the DI style, I don't think DI is an option for an API (unless the API is some sort of runtime container). An API is usually called by the user, while the DI framework calls the user classes. Turning it the other way around and enforcing your DI impl on the user hurts in many ways.
Also using an injectable singleton the code stays slightly cleaner, since you can keep it's reference in any scope, while DI always makes everything a member variable (unless you perform work in a setter or constructor, which is against convention or complicates testing).
--Johannes W. 17:01, 7 December 2012 (CET)