如果我理解正确，依赖注入的典型机制是注入通过类的构造函数或通过类的公共属性(成员)。
这暴露了注入的依赖性，并违反了封装的OOP原则。
我在确定这种权衡是正确的吗？您如何处理这个问题？
还请参见我对自己的问题的答案。
有另一种方法来看这个问题，你可能会感兴趣。
当我们使用IoC /依赖注入时，我们不使用OOP概念。不可否认，我们使用OO语言作为“主机”，但是IoC背后的想法来自于面向组件的软件工程，而不是OO。
组件软件都是关于管理依赖关系的 – 一个常见的例子是.NET的装配机制。每个程序集都发布它引用的程序集列表，这使得更容易集中(并验证)正在运行的应用程序所需的部分。
通过IoC在我们的OO程序中应用类似的技术，我们的目标是使程序更易于配置和维护。发布依赖关系(作为构造函数参数或其他)是关键的一部分。封装并不真正适用，因为在组件/服务导向的世界中，没有’实现类型’的详细信息泄漏。
不幸的是，我们的语言目前没有将粗粒度的，面向对象的概念与粗粒度的面向组件的概念隔离，所以这是一个区别，你只能在你的心中持有:)
