Design patterns 控制反转是否特定于OO语言？

问这个问题的另一种方式是：你认为什么是控制反转

我问这个问题是因为维基百科关于的文章被一个非面向对象的解释劫持了。这是从2007年开始的：

我冒昧地完全重写了页面，因为之前的内容完全被毫无意义的“面向对象”废话所取代

在OO语言之外，我看不出控制反转有什么意义。对于放弃过程语言中的控制，已经有很多解释（事件编程就是其中之一），纯函数语言不需要像控制反转这样的概念，因为它们具有高阶函数

此外，在Martin Fowler阐述IoC的文章中，他专门处理OO示例

那么，国际奥委会是否只是一个面向对象的概念，它到底是什么

对我来说，IoC试图在大多数OO语言所施加的限制范围内将函数转换为数据，并试图将这些函数作为参数传递给其他函数。这不是国际奥委会的唯一部分，但也有一些

还有工厂设计模式，在传递之前，正在构建和配置对象树

对我来说，国际奥委会完全是一个面向对象的概念

你的答案是什么？

嗯，“控制反转”的概念似乎适用于任何你有办法传递函数指针的地方。基本上，插件概念和具有兼容签名的DLL（例如，想想驱动程序）只不过是IoC的一种形式

---

然而，当使用具有丰富类型和容器模型的IoC时，您基本上会自动进入OO世界。OOP的概念非常符合IoC的概念，特别是在支持纯虚拟类（或“接口”，也被称为“接口”）多重继承的语言中。

控制反转绝对不是OO概念

IoC存在，并且在非OO语言中使用得相当频繁。例如，它在C语言中非常常见。这方面的一个主要例子是Windows API—无论何时调用任何通过回调工作的Windows API函数，基本上都是以最原始的形式使用IoC

例如，看看函数。使用此方法，您可以将函数指针（EnumWindowsProc）传递到库，代码将从库代码中运行

将此与Wikipedia中控制反转的定义进行比较：“控制反转发生在库过程调用用户过程时。”

完全一样

---

然而，当您添加富类型系统和OOP附带的许多其他工具时，IoC确实变得非常强大、灵活且易于使用。这使得它更为常见，因为使用它“更好”，但它在OOP之前确实存在。

您可以从实现的角度来看待理论问题。出现的第一个问题应该是您到底反转了什么控制

然后，您将认识到，它是一个对象、方法、函数还是其他被传递的东西并不重要，而是代码的实际功能

简言之，当您执行依赖项注入时，您将反转对依赖项（资源）的创建和使用的控制

当您给Windows API函数一个指向回调函数的指针时，您给了它们使用自己的参数调用函数的控制权

---

所以你看，IoC只是一个理论概念，当然，它可以有不同的实际实现。

事实上，IoC的OO实现非常复杂，因为函数通常不是一等公民

正如阿兹德所提到的：使用国际奥委会有很多原因。我会在这里总结一些来说服：）

迭代

#ruby
{1,2,3}.each{ |i| puts i }

#haskell
map [1,2,3] ( \i -> write i )

//the stl algorithms
int printint( int i ){ return printf( "%d", i ); }
std::foreach( onetwothree.begin(), onetwothree.end(), &printi );

线程创建

CreateThread( NULL, 0, &myFunction, NULL, 0, NULL );

一般事件调度

//javascript
document.getElementById( "mybutton" )
            .addEventListener( 
                 function(e){ alert("buttonPressed") } );

---

这些示例都不是面向对象的，q.e.d.

完全同意它更容易与富类型系统一起使用。作为一等公民，它变得更加容易。