Python 中有依赖注入容器吗？

Question

一直在摆弄 python，像往常一样，它让我严格的静态类型面向对象世界变得有点混乱。 Python 支持鸭子类型，没有基于接口的编程的可用概念（如 C# 接口）并允许全局变量。有了所有这些好处，依赖注入容器真的有任何意义吗？或者 Python 运行时是否会成为容器。

我理解这些容器在静态类型 OO 语言（例如 Java 和 C#）中的意义，但是这样的东西如何适合 Python 的疯狂世界（我喜欢它）？

我一直怀疑依赖注入作为一种设计模式是一种难闻的气味，一切事物都必须是 C# 和 Java 的“纳粹思维”类，我是正确的还是有什么我遗漏的？

到目前为止，我认为我可以通过使用全局来涵盖工厂、单例、多实例对象。我还怀疑 Aspect 的内容也被涵盖了，尽管我仍在考虑这一点。

Duck Typing 是目前让我着迷的东西，所以习惯于定义接口，然后在这些接口上建立类，并让静态的东西掩盖我的愚蠢，我觉得没有静态类型，容器有点无用。

Answer 1

没有基于接口的编程的可用概念（如 C# 接口）

仅仅因为编译器无法检查您是否正确使用接口并不意味着“没有可用的接口概念”。您记录接口并编写单元测试。

至于全局变量，它与 C# 或 Java 类上的 public static 方法和字段没有什么不同。例如，考虑 java.lang.Math 的工作原理。现在考虑一下 java.lang.Math 不是 Singleton 的事实。他们这样做是有充分理由的。

有了所有这些好处，依赖注入容器真的有任何意义

，我对此表示怀疑，但我也从未真正在 C# 或 Java 中看到它们的意义。在我看来，依赖注入是一种编程技术。而且实际上也没有那么多。

我一直怀疑依赖注入作为一种设计模式是一种恶臭，一切事物所创造的一定是一类“纳粹思维”

，不，不是。很多时候依赖注入是一个好主意。您也不需要一个类来注入依赖项。每次您将某些内容作为参数传递给自由函数时，而不是让该函数调用另一个函数来获取信息，您基本上都在做同样的事情：控制反转。 Python 还允许您在很多方面将模块视为类（当然比 Java 和 C# 的方式更多）。有些问题可以通过将模块作为参数传递给函数来解决。 :)

到目前为止，我认为只需使用全局变量，我就可以涵盖工厂、单例、多实例对象。

如果有的话，单身人士就是难闻的气味。根据我的丰富经验，几乎在每种情况下，它们的存在都是因为有人认为原则上拥有全局变量是不好的，而没有真正考虑可能的选项，或者为什么他们想要对单个共享对象进行这种访问，或者甚至是为什么全局变量从一开始就是“Bad(TM)”。

您可以在Python中创建一个充当工厂的全局函数。然而，我想说，做以下任何事情都更Pythonic：

a）首先，真的，真的，真的确保你不能只是用__init__。我的意思是，在动态类型语言中，您可以通过这种方式做很多事情。

b) 如果 __init__ 不能解决问题，请尝试使用 __new__ 来控制行为。

在Python中，类本身就是对象，是可调用的。默认情况下，调用它们会实例化该类。使用__new__，您可以连接到它。

c) 使用应用于类的装饰器。下面是一个创建 Singleton 的示例（只是因为）：

def _singleton(cls):
  instance = cls()
  result = lambda: instance
  result.__doc__ = cls.__doc__
  return result

@_singleton
class example(object): pass

工作方式：当您装饰类时，调用 _singleton() 并传入该类。构造并缓存一个实例，并且 _singleton() 返回一个匿名函数，该函数在调用时将返回实例。为了完成这个谜题，类的文档被附加到匿名函数上。然后Python将全局范围内的类名重新绑定到返回的匿名函数。因此，当您调用它时，每次都会获得该类的相同实例。

现在，当然，这仍然可以解决（您可以执行诸如 example().__class__() 之类的操作来获取另一个实例），但更明显的是，您做错了事情，而不是如果您只是为了正常使用构造函数而忽略了工厂函数。另外，这意味着调用代码实际上就像正常调用构造函数一样:)

鸭子类型是目前让我着迷的东西，所以习惯于定义接口，然后基于这些接口创建类，并让静态的东西掩盖我的愚蠢，我觉得没有静态类型，容器有点无用。

你需要转变你的思维：不要再担心你传递给你的东西是什么，而是担心它是否能做你想让它做的事情。这就是鸭子打字的工作原理。

Answer 2

结论

（以下是原帖中最相关的部分。我承认，我有点诗意了，所以我想我应该简单地将最重要的句子包含在他们自己的部分中。也就是说，我觉得诗意的增加非常重要，我还没有删除它。）

依赖注入仍然被使用。对象总是需要与已经实例化的对象进行通信。需要“父”对象（或容器，或其他）来设置其“子”的状态。这些需要通过某种方法传入或通过某种赋值进行设置，但从抽象意义上来说，它们是同一件事。

原始答案：

类型系统

从很多方面来说，Python 是我遇到过的第二个最纯粹的数学语言——它只遵循Scheme（虽然我从未使用过 Haskell，但我知道这一点也很高）。

Python 原生支持闭包，它具有延续（yield 语法）、多重继承和循环理解语法，这在很大程度上是无与伦比的。所有这些使它更接近 Alonzo Church 在 Lambda Calculus 中的最初设想（麦卡锡在 Lisp 背后的最初想法）。 Python 3 通过集合推导式使其变得更加纯粹（一想到它们与生俱来的美就让我心潮澎湃）。

人们不断地认为，存储在 Python 变量中的数据与数学中的对应数据有更多共同点，以至于对象的接口可以简化为简单的“形容词或形容词集，它们描述了对象”。基本上，对象的接口完全包含在其 __dict__ 中，并通过 dir 显示。

考虑到所有这些，它确实开始让人怀疑“传统”的看待事物的方式（“传统”加引号是因为 Python 和 Java 一样古老）是否真的可以在这样一种语言中工作。当 Python 中的参数列表也有 OOP 的感觉时（kwargs，有人吗？），它确实把世界颠倒了。

仍然使用依赖注入。对象总是需要与已经实例化的对象进行通信。需要“父”对象（或容器，或其他）来设置其“子”的状态。这些需要通过某种方法传入或通过某种赋值进行设置，但从抽象意义上来说，它们是同一件事。但存在一种隐含的信任，即传递的对象的 __dict__ 的内容将包含适当的描述。正因为如此，它变得少得多，“一旦我实例化了这个对象，我就会赋予它生命所需的东西”，而更多的是，“嗯，是的，一个对象需要一个状态，所以我给它一个。”

这暴露了静态类型的一个隐藏的方面。为了让需要 IFoo 的东西能够工作，它必须完全了解 IFoo 的含义，即使它永远不需要 90%该定义的。同时，鸭子类型使依赖对象只知道属性 X、Y 和 Z 应该在运行时存在。

全局变量

至于全局变量。除非您别无选择，否则请避免使用它们。您最好使用单例，因为单例允许您在值更改时进行记录。对于全局变量来说情况并非如此。

编程有一条规则，界面越暴露、越复杂，维护起来就越困难。如果某些内容被放置在全局变量中，则该模块中的任何，以及ANY模块中的任何都可以修改值。代码几乎可能变得不确定。我向你保证，悲伤随之而来。