python - Python 中的依赖注入(inject)容器是否有意义？

Question

一直在搞 python，像往常一样，它把我僵硬的静态类型的面向对象的世界弄得一团糟。 Python 支持鸭子类型，没有可用的基于接口(interface)的编程概念(如在 C# 接口(interface)中)并允许全局变量。有了所有这些好东西，依赖注入(inject)容器真的有任何意义，还是 Python 运行时成为容器。

我理解在静态类型的 OO 语言(例如 Java 和 C#)中使用这些容器的意义，但是这样的东西在 Python 的疯狂世界中适合什么地方(我喜欢它)？

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

到目前为止，我认为我可以通过使用 Globals 来涵盖工厂、单例、多实例对象。我还怀疑 Aspect 的东西也被涵盖了，尽管我还在考虑这个问题。

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

编辑

我想我在使用 python 时不会使用依赖注入(inject)器框架/容器。真的没有任何意义。到目前为止，在思考和阅读响应之后，论点很清楚，如果没有静态类型定义，所做的 promise 就太松散了，根本不用担心。鸭子打字就是这样，唯一的 promise 可以通过文档来实现。只要引用通过签名参数进入类方法/函数，而不是通过编程环境的以太网，那么我认为我会很安全。

但令人担忧的是，我无法像在 Java 和 C# 中那样通过过度设计实践将自己的意志强加于人。我在乎……不:)

Answer 1

has no usable concept of interface based programming (as in C# interfaces)

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

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

With all these goodies is there really any point to a dependency injection container

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

I have always suspected that Dependency injection as a design pattern was a bad smell that has been created by everything must be a class "Nazi thinking"

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

So far I think I can cover factories, Singletons, Multi-instance objects, just by using Globals.

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

您可以在 Python 中创建一个充当工厂的全局函数。但是，我会说执行以下任何操作都更符合 Pythonic:

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

b) 如果 __init__ 不会削减它，请尝试使用 __new__ 来控制行为。

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

c) 使用应用于类的装饰器。这是一个创建单例的示例(只是因为):

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

@_singleton
class example(object): pass

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

现在，这仍然可以解决，当然(您可以执行 example().__class__() 之类的操作来获取另一个实例)，但更清楚的是您正在做与为了正常使用构造函数而简单地忽略工厂函数相比，这是错误的。另外，这意味着调用代码实际上就像在正常调用构造函数一样:)

The Duck Typing is the thing that is getting me at the moment, so used to defining interfaces then basing classes on these interfaces and letting the static stuff cover my stupidity that I feel that without static typing, containers are a bit useless.

你需要转变你的想法:不要再担心你通过的东西是什么，而要担心它是否能做你想让它做的事 .这就是鸭子打字的工作原理。