Skip to main content
Wanted to specifically answer the original questions stated in the post.
Source Link

I feel a little awkward answering this question with so many prior answers, but I just didn't think any of the answers just stated the concept simply enough.

So here we go...

In a non-IOC application, you would code a process flow and include all the detailed steps in it. Consider a program that creates a report - it would include code to set up the printer connection, print a header, then iterate through detail records, then print a footer, maybe perform a page feed, etc.

In an IOC version of a report program, you would configure an instance of a generic, reusable Report class - that is, a class that contains the process flow for printing a report, but has none of the details in it. The configuration you provide might use DI to specify what class the Report should call to print a header, what class the Report should call to print a detail line, and what class the Report should call to print the footer.

So the inversion of control comes from the controlling process not being your code, but rather contained in an external, reusable class (Report) that allows you to specify or inject (via DI) the details of the report - the header, the detail line, the footer.

You could produce any number of different reports using the same Report class (the controlling class) - by providing different sets of the detail classes. You are inverting your control by relying on the Report class to provide it, and merely specifying the differences between reports via injection.

In some ways, IOC could be compared to a drive backup application - the backup always performs the same steps, but the set of files backed up can be completely different.

Anyway, hope that helpsAnd now to answer the original questions specifically...

  • What is it? IOC is relying on a reusable controller class and providing the details specific to your problem at hand.
  • Which problem does it solve? Prevents you from having to restate a controlling process flow.
  • When is it appropriate to use and when not? Whenever you are creating a process flow where the control flow is always the same, and only the details are changed. You would not use it when creating a one-off, custom process flow.

AlsoFinally, IOC is not DI, and DI is not IOC - DI can often be used in IOC (in order to state the detail classesdetails of the abstracted control class).

Anyway - I hope that helps.

I feel a little awkward answering this question with so many prior answers, but I just didn't think any of the answers just stated the concept simply enough.

So here we go...

In a non-IOC application, you would code a process flow and include all the detailed steps in it. Consider a program that creates a report - it would include code to set up the printer connection, print a header, then iterate through detail records, then print a footer, maybe perform a page feed, etc.

In an IOC version of a report program, you would configure an instance of a generic, reusable Report class - that is, a class that contains the process flow for printing a report, but has none of the details in it. The configuration you provide might use DI to specify what class the Report should call to print a header, what class the Report should call to print a detail line, and what class the Report should call to print the footer.

So the inversion of control comes from the controlling process not being your code, but rather contained in an external, reusable class (Report) that allows you to specify or inject (via DI) the details of the report - the header, the detail line, the footer.

You could produce any number of different reports using the same Report class (the controlling class) - by providing different sets of the detail classes. You are inverting your control by relying on the Report class to provide it, and merely specifying the differences between reports via injection.

In some ways, IOC could be compared to a drive backup application - the backup always performs the same steps, but the set of files backed up can be completely different.

Anyway, hope that helps.

Also, IOC is not DI, and DI is not IOC - DI can often be used in IOC (in order to state the detail classes).

I feel a little awkward answering this question with so many prior answers, but I just didn't think any of the answers just stated the concept simply enough.

So here we go...

In a non-IOC application, you would code a process flow and include all the detailed steps in it. Consider a program that creates a report - it would include code to set up the printer connection, print a header, then iterate through detail records, then print a footer, maybe perform a page feed, etc.

In an IOC version of a report program, you would configure an instance of a generic, reusable Report class - that is, a class that contains the process flow for printing a report, but has none of the details in it. The configuration you provide might use DI to specify what class the Report should call to print a header, what class the Report should call to print a detail line, and what class the Report should call to print the footer.

So the inversion of control comes from the controlling process not being your code, but rather contained in an external, reusable class (Report) that allows you to specify or inject (via DI) the details of the report - the header, the detail line, the footer.

You could produce any number of different reports using the same Report class (the controlling class) - by providing different sets of the detail classes. You are inverting your control by relying on the Report class to provide it, and merely specifying the differences between reports via injection.

In some ways, IOC could be compared to a drive backup application - the backup always performs the same steps, but the set of files backed up can be completely different.

And now to answer the original questions specifically...

  • What is it? IOC is relying on a reusable controller class and providing the details specific to your problem at hand.
  • Which problem does it solve? Prevents you from having to restate a controlling process flow.
  • When is it appropriate to use and when not? Whenever you are creating a process flow where the control flow is always the same, and only the details are changed. You would not use it when creating a one-off, custom process flow.

Finally, IOC is not DI, and DI is not IOC - DI can often be used in IOC (in order to state the details of the abstracted control class).

Anyway - I hope that helps.

Source Link

I feel a little awkward answering this question with so many prior answers, but I just didn't think any of the answers just stated the concept simply enough.

So here we go...

In a non-IOC application, you would code a process flow and include all the detailed steps in it. Consider a program that creates a report - it would include code to set up the printer connection, print a header, then iterate through detail records, then print a footer, maybe perform a page feed, etc.

In an IOC version of a report program, you would configure an instance of a generic, reusable Report class - that is, a class that contains the process flow for printing a report, but has none of the details in it. The configuration you provide might use DI to specify what class the Report should call to print a header, what class the Report should call to print a detail line, and what class the Report should call to print the footer.

So the inversion of control comes from the controlling process not being your code, but rather contained in an external, reusable class (Report) that allows you to specify or inject (via DI) the details of the report - the header, the detail line, the footer.

You could produce any number of different reports using the same Report class (the controlling class) - by providing different sets of the detail classes. You are inverting your control by relying on the Report class to provide it, and merely specifying the differences between reports via injection.

In some ways, IOC could be compared to a drive backup application - the backup always performs the same steps, but the set of files backed up can be completely different.

Anyway, hope that helps.

Also, IOC is not DI, and DI is not IOC - DI can often be used in IOC (in order to state the detail classes).