Everything fits into the Dependency injection pattern.
When ol' Wirth was proclaiming that every Pascal program should begin with
it was dependency injection that he had in mind, albeit in a very rudimentary form, and we did not even have a word for it yet, so generations upon generations of programmers never understood it, and instead copied it from program to program as some apocryphal words that just had to be written this way for the magic to work.
Explicitly passing the input stream and the output stream to your program instead of having your program rely on some pre-determined, fixed, globally available entities is, in a sense, dependency injection.
Allegedly for the sake of convenience, modern languages offer many globally available features that are at your disposal simply with an
#include or a
using or an
import statement. These import statements do not import just interfaces and primitive constants; they also import entire subsystems declared as
public static, ready to be used by anyone.
Does your sorting routine sometimes become bored while sorting, and feels the need to check out its facebook account? Just have your sorting routine
io.net package from the SDK, and it can now access any gossip all over the entire planet.
Do your web services feel that their job is kind of lackluster and they'd prefer to do something more glamorous while waiting for the remote host to respond? They can just
import java.awt from the SDK, and display some slick 2D graphics for the amusement of whoever happens to walk by the server console at that moment.
All this insanity exists because the concept of dependency injection has not yet gained the traction it deserves.
Everything could, and in my opinion should, be done using dependency injection; instead of your console application's entry point being
int main( String args )
it could be
void main( ConsoleRuntimeEnvironment environment )
in which case you would be invoking the environment to get your arguments, and invoking it again to exit returning a result code.
If your application is a graphics application, it could be
void main( Graphical2DRuntimeEnvironment environment )
If it is a web service it could be
void main( WebServiceRuntimeEnviroment environment )
...and so on and so forth.
Whatever services, features, libraries, call them what you like you need, you should be able to obtain by asking your environment for them, and the
public static keyword combination should be prohibited for anything but primitives.
But while nobody enforces this style of doing things, nothing prevents you from doing it voluntarily. You can inject anything as a dependency. Want some examples that you can use right now in applications that are currently sitting in your hard drive?
Come up with a
Logger interface and pass it to all of your classes instead of magically using some omnipresent, omnipotent, and ultimately evil, statically available logging facility.
Come up with a
Clock interface and pass it to any code that needs the current time, so that you do not obtain the current time using
new Instance(), thus making your time-dependent code testable.
Come up with a
FileSystem interface and pass it to any code of yours that needs to deal with files, so that it does not use the
new operator to directly instantiate classes from
java.io. This way, your file-manipulation code can be tested using a filesystem implemented in memory, so your tests can be much faster.
And the list goes on.