值对象是DI设计模式的有效依赖项吗?

Question

对于我见过的所有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只是为了单元测试(喘息我甚至不是单元测试，现有的项目)。我只是想把我的依赖性/创造性关注和逻辑关注分开。

Answer 1

如果你想注入的东西，例如文件位置，是类直接使用的东西，那么注入它是完全有效的。

在File或String等Object的情况下，这与称为Service的东西没有什么不同。它是类的依赖项，因此应用DI。