I can see why this discussion goes in divergent directions, with different people giving different answers.

Dependency Injection describes a technique in object oriented programming (OOP). Meanwhile, your sample code isn't OOP.

The goal of Dependency Injection is to have flexibility - to allow a piece of client code to work with a choice of different service implementations, without requiring the client code to be recompiled. To this end, your non-OOP sample code seems to have the same kind of flexibility, even though it is non-OOP.

As noted by others, your code contains some characteristics of service locator, plugin system, and IoC container configuration using configuration files.

Though, because your sample code is non-OOP, programmers who are deep into OOP can't use their rules-of-thumb to judge whether your code fits a certain OOP pattern.

With respect to Dependency Injection, OOP programmers will ask these questions:

1. Are there different service implementations? (e.g. S1, S2, S3, ...)
2. Do these service implementations implement the same interface (I)? Or do they all derive from the same abstract base class (S)?
3. Does the client (application code) use the service implementation strictly in accordance with the interface (via I or S)?
4. Is the client code encapsulated into an object (C)?
5. When the client object (C) is initializing (e.g. in the constructor, or shortly after having been constructed), does it allow the user of this object (the owner of C, therefore not part of C but at a higher command level) to specify which service implementation to use, by passing in an instance of that implementation?

Condition #5 is the uniquely-identifying characteristic of dependency injection. For OOP programmers, they will jump to condition #5 without verifying conditions #1 - #4. It is because OOP programmers took these for granted. Therefore, OOP programmers will ask to see the constructor or the property-setters of the client object (C). Your code doesn't have these.

When applying these conditions to your sample code, the results are:

1. Yes
2. Yes. However, the "interface" is not based on OOP-style interface or abstract base class. Instead, it is based on C-style function pointers.
3. Yes.
4. No. There is an "application" that runs a menu-driven application loop.
5. Not applicable. The application code is already at the highest command level; there is no other "code". In some sense, the only higher command level is the (human) user who gives keyboard input to the program.

I can see why this discussion goes in divergent directions, with different people giving different answers.

Dependency Injection describes a technique in object oriented programming (OOP). Meanwhile, your sample code isn't OOP.

The goal of Dependency Injection is to have flexibility - to allow a piece of client code to work with a choice of different service implementations, without requiring the client code to be recompiled. To this end, your non-OOP sample code seems to have the same kind of flexibility, even though it is non-OOP.

As noted by others, your code contains some characteristics of service locator, plugin system, and IoC container configuration using configuration files.

Though, because your sample code is non-OOP, programmers who are deep into OOP can't use their rules-of-thumb to judge whether your code fits a certain OOP pattern.

With respect to Dependency Injection, OOP programmers will ask these questions:

1. Are there different service implementations? (e.g. S1, S2, S3, ...)
2. Do these service implementations implement the same interface (I)? Or do they all derive from the same abstract base class (S)?
3. Does the client (application code) use the service implementation strictly in accordance with the interface (via I or S)?
4. Is the client code encapsulated into an object (C)?
5. When the client object (C) is initializing (e.g. in the constructor, or shortly after having been constructed), does it allow the user of this object (the owner of C, therefore not part of C but at a higher command level) to specify which service implementation to use, by passing in an instance of that implementation?

Condition #5 is the uniquely-identifying characteristic of dependency injection. For OOP programmers, they will jump to condition #5 without verifying conditions #1 - #4. It is because OOP programmers took these for granted. Therefore, OOP programmers will ask to see the constructor or the property-setters of the client object (C). Your code doesn't have these.

When applying these conditions to your sample code, the results are:

1. Yes
2. Yes. However, the "interface" is not based on OOP-style interface or abstract base class. Instead, it is based on C-style function pointers.
3. Yes.
4. No. There is an "application" that runs a menu-driven application loop.
5. Not applicable. The application code is already at the highest command level; there is no other "code". In some sense, the only higher command level is the (human) user who gives keyboard input to the program.

Edited: Suppose we stretch the definition of OOP to cover C-style function pointers and explicit vtables. Here is my response:

The essence of Dependency Injection is that, after you have obtained a pointer to an imagehandler, as in:

// ih is a pointer to a struct that contains three function pointers
ih = imagehandlers[handleno]; 

that you have other functions that accepts the ih pointer as a function parameter (input argument). This is the essence.

I can see why this discussion goes in divergent directions, with different people giving different answers.

Dependency Injection describes a technique in object oriented programming (OOP). Meanwhile, your sample code isn't OOP.

The goal of Dependency Injection is to have flexibility - to allow a piece of client code to work with a choice of different service implementations, without requiring the client code to be recompiled. To this end, your non-OOP sample code seems to have the same kind of flexibility, even though it is non-OOP.

As noted by others, your code contains some characteristics of service locator, plugin system, and IoC container configuration using configuration files.

Though, because your sample code is non-OOP, programmers who are deep into OOP can't use their rules-of-thumb to judge whether your code fits a certain OOP pattern.

With respect to Dependency Injection, OOP programmers will ask these questions:

1. Are there different service implementations? (e.g. S1, S2, S3, ...)
2. Do these service implementations implement the same interface (I)? Or do they all derive from the same abstract base class (S)?
3. Does the client (application code) use the service implementation strictly in accordance with the interface (via I or S)?
4. Does the client code encapsulated into an object (C)?
5. When the client object (C) is initializing (e.g. in the constructor, or shortly after having been constructed), does it allow the user of this object (the owner of C, therefore not part of C but at a higher command level) to specify which service implementation to use, by passing in an instance of that implementation?

For OOP programmers, they will jump to condition #5 without verifying conditions #1 - #4. It is because OOP programmers took these for granted.

When applying these to your sample code, the results are:

1. Yes
2. Yes. However, the "interface" is not based on OOP-style interface or abstract base class. Instead, it is based on C-style function pointers.
3. Yes.
4. No. There is an "application" that runs a menu-driven application loop.
5. Not applicable. The application code is already at the highest command level; there is no other "code". In some sense, the only higher command level is the (human) user who gives keyboard input to the program.

Your code doesn't have objects in the OOP sense, therefore there is no constructor. Your code only performs a single action on a given filename. This is where the rules-of-thumb fails to recognize the pattern.

I can see why this discussion goes in divergent directions, with different people giving different answers.

Dependency Injection describes a technique in object oriented programming (OOP). Meanwhile, your sample code isn't OOP.

The goal of Dependency Injection is to have flexibility - to allow a piece of client code to work with a choice of different service implementations, without requiring the client code to be recompiled. To this end, your non-OOP sample code seems to have the same kind of flexibility, even though it is non-OOP.

As noted by others, your code contains some characteristics of service locator, plugin system, and IoC container configuration using configuration files.

Though, because your sample code is non-OOP, programmers who are deep into OOP can't use their rules-of-thumb to judge whether your code fits a certain OOP pattern.

With respect to Dependency Injection, OOP programmers will ask these questions:

1. Are there different service implementations? (e.g. S1, S2, S3, ...)
2. Do these service implementations implement the same interface (I)? Or do they all derive from the same abstract base class (S)?
3. Does the client (application code) use the service implementation strictly in accordance with the interface (via I or S)?
4. Is the client code encapsulated into an object (C)?
5. When the client object (C) is initializing (e.g. in the constructor, or shortly after having been constructed), does it allow the user of this object (the owner of C, therefore not part of C but at a higher command level) to specify which service implementation to use, by passing in an instance of that implementation?

Condition #5 is the uniquely-identifying characteristic of dependency injection. For OOP programmers, they will jump to condition #5 without verifying conditions #1 - #4. It is because OOP programmers took these for granted. Therefore, OOP programmers will ask to see the constructor or the property-setters of the client object (C). Your code doesn't have these.

When applying these conditions to your sample code, the results are:

1. Yes
2. Yes. However, the "interface" is not based on OOP-style interface or abstract base class. Instead, it is based on C-style function pointers.
3. Yes.
4. No. There is an "application" that runs a menu-driven application loop.
5. Not applicable. The application code is already at the highest command level; there is no other "code". In some sense, the only higher command level is the (human) user who gives keyboard input to the program.