对于我见过的所有 DI 示例，我总是将依赖项视为其他类，例如服务。但实际上，一个对象可能在很大程度上和/或至关重要地依赖于配置值，例如字符串和资源包装器（文件/路径/URI/URL，而不是整个大值字符串/文档或阅读器）。
请注意，这是关于 Java 或 C# 语法中的 DI 设计模式，而不是任何特定的 DI 框架如何处理这个问题。
例如，假设我有一个返回 String 的类（相对路径，基于一些模糊的实现逻辑）。它（而不是它的各种实现者）对“projectLocation”具有配置/初始化依赖性，因为用户可以在他们的机器上拥有各种项目，并且这个类将在调用时基于给定项目执行一些逻辑。
public abstract class PathResolver {
protected File projectFilesLocation;
public RoutinePathResolver(File projectFilesLocation) {
this.projectFilesLocation = projectFilesLocation;
}
public abstract String getPath(String someValue);
}
我不只是将 DI 用于单元测试（喘气，我什至没有单元测试，现有项目）。我只想将我的依赖/创建关注点和逻辑关注点分开。