CompilationUnit对象应该具有保存自身并编译到磁盘的功能吗？

Question

我从来不知道如何正确地对以后要保存在磁盘上的数据结构进行建模。

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

class CompilationUnit {
    String qualifiedName;
    String contents;
}

现在，我的问题是如何对此进行建模。我是否应该有一个同时接受IFileSystem和IJavaCompiler作为参数的CompilationUnit，这样每当我有一个“手中”的CompilationUnit时，我就有了执行这两个操作所需的所有东西，或者我是否应该尝试将编译逻辑保留在类之外，使CompilationUnit只是一个数据对象？

一方面，OO相信人们应该将状态和行为都保存在同一个对象上，这有利于保留限定名称及其内容，以及将编译单元写入磁盘并编译它的可能性。

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

我的(理想主义者？)直觉是，数据对象应该易于实例化，在这种情况下，每次我想要将限定名称及其内容存储在一起时，都必须传入IFileSystem和IJavaCompiler，这肯定会让人感到尴尬。这意味着，无论谁负责生成这些数据，都必须同时访问IFileSystem和IJavaCompiler，这有点奇怪。

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

该系统将经过测试，因此正确处理依赖关系问题至关重要。

谢谢!

Answer 1

如果您将服务注入到实体或值对象中，则很可能会破坏Single Responsibility Principle。虽然我不知道这个域的细节，但对我来说，IFileSystem和IJavaCompiler听起来很像服务-它们实际上不是对象状态的一部分，而是它可以使用的服务。