注入的依赖项应该是可公开访问的还是私有的

本文关键字：访问 注入 依赖 | 更新日期: 2023-09-27 18:36:48

依赖项是否应该存储到私有字段或具有私有资源库和公共获取器的属性中？这适用于构造函数 DI。

需要明确的是，在属性示例中，除非有意义，否则我不希望将它们添加到随附的接口中 - 即它们仅在实现类型中可见：

interface IFoo {
  void DoSomething();
}
class Foo : IFoo {
  private readonly IService dependency;
  public Foo(IService dependency) {
    this.dependency = dependency;
  }
}
class Bar : IFoo {
  public Foo(IService dependency) {
    this.Dependency = dependency;
  }
  public IService Dependency { get; private set; }
}

注入的依赖项应该是可公开访问的还是私有的

我总是建议private readonly字段，只要不需要从对象外部访问依赖项。将对象视为"黑匣子"，并尽可能少地放入其公共接口中。这种做法更广为人知的是封装原则或信息隐藏，也适用于注入的依赖关系：暴露得越少，就越能减少类和类用户之间的紧密耦合。

另一个应该提到的原则是对象的行为建模：告诉，不要问。如果你需要完成某件事，请对象为你做。它将在此过程中使用其依赖项。请求属性并自己完成工作应该只是数据对象 （DTO） 的首选。

这也是首先使用构造函数注入的原因：如果将依赖项公开为属性是最佳实践，那么每个人都会进行属性注入，因为这意味着更少的代码（那时我们不需要构造函数）。

这完全取决于您是否需要允许使用对象在已使用对象的生存期内更改依赖项。

在构造函数上使用 DI 可以为您设置两件事：

  • 它正在定义一个合约，说"这个类需要这个特定的依赖关系来运行"
  • 它允许您通过注入不同的实现（即在单元测试时注入模拟实现，或者您在使用 MVVM 时有一个可以采用多个视图模型中的任何一个的视图等）来轻松操作使用的依赖项。

如果你喜欢保持你的对象不可变，那么公共getter和私有setter就是你要走的路。然而，事情并不总是那么简单 - 一个对象的寿命可能很长，并且很容易出现需要更改依赖关系的情况。

DR：这要看情况。当你编写大型应用程序时，你会发现你需要混合你的方法 - 你将在ctor中定义依赖关系，但对于其中一些，你需要在创建对象后更改它们。

我同意@Frank你必须保持私密，它更适合测试，它给你一个更好的对象封装。

想象一下，您有一个接口只需要访问 Bar 类，在这种情况下，您的客户可以执行某些操作Bar.Dependency.BadMethodBurnTheDevice();

相关文章：