CompilationUnit 对象是否应该具有保存自身并编译到磁盘的方法？

Question

当我想要稍后保存在磁盘上的这种数据结构时，我永远不知道如何正确地模拟情况。

例如，我目前正在开发一个小型代码生成器。一般的想法是，我想在某个地方存储一个类的限定名及其相关内容，然后我想将 .java 文件保存到磁盘并通过javac 编译它。不完全清楚我是否要同时执行这两个操作，也就是说，将作为 .java 保存到磁盘并通过 javac 编译作为一个操作。我想有时我可能只想将 .java 文件写入磁盘而不进行编译。

class CompilationUnit {
    String qualifiedName;
    String contents;
}

现在，我的问题是如何对此建模。我是否应该有一个CompilationUnit 将IFileSystem 和IJavaCompiler 作为参数，所以每次我“手中”有一个CompilationUnit 时，我都拥有执行这两个操作所需的一切，或者我应该尽量保持类之外的编译逻辑，作为CompilationUnit 只是一个数据对象？

一方面，这种面向对象的信念应该将状态和行为都保留在同一个对象上，这将有利于将限定名称及其内容与将编译单元写入磁盘并进行编译的可能性保持在一起。

尽管如此，我还是对让CompilationUnit 同时使用IFileSystem 和IJavaCompiler 依赖项的想法感到不舒服，尽管我很难解释为什么会这样。

我的（理想主义者？）直觉是数据对象应该易于实例化，在这种观点中，每次我想存储一个合格的对象时，不得不传入 IFileSystem 和 IJavaCompiler名称及其内容。这意味着负责生成这些数据的人还必须同时访问IFileSystem 和IJavaCompiler，这有点奇怪。

我不确定我是否真的回答了我自己的问题。

这个系统将被测试，所以正确处理依赖问题是最重要的。

谢谢！

Answer 1

如果您将 Services 注入到 Entities 或 Value Objects，您很可能会破坏 Single Responsibility Principle。虽然我不知道这个域的详细信息，但 IFileSystem 和 IJavaCompiler 在我看来很像 Services - 它们并不是真正的 state 的一部分对象，但它可以使用的服务。