java - 具有副作用的不可变对象(immutable对象)

Question

让我们考虑封装fileName 的不可变对象(immutable对象)File，它指向磁盘上的文件。该对象具有方法 rename，这显然是为磁盘上的文件分配新名称。

public final class File {

   private final String fileName;

   public File(String fileName fileName) {
       this.fileName = fileName;
   }

   public File rename(String newName) {
        // Rename the actual file on the disk (code is omitted)
        // and that is the side effect!
        return new File(newName);
   }
}

所以问题是:

• 如何处理不可变对象(immutable对象)的副作用？我们的 File 对象一旦创建，就应该始终以相同的封装状态工作。并返回具有修改状态的新对象。这在 java.lang.String 类中完美地完成了。但是旧对象(仍然指向错误 fileName)并不好。我们无法使用它，因为状态已损坏。
• 这是否意味着对象不是真正不可变的？如果我们只想处理具有一致状态的真正不可变对象(immutable对象)怎么办？我们不应该重命名磁盘上的文件吗？但是当我们真正需要重命名文件时如何完成工作呢？

假设 File 只是一个例子。

Answer 1

How to approach side effects with immutable objects? Our File object once created should be working always with the same encapsulated state. And return new object with modified state. This is perfectly done in java.lang.String class. But the old object (which is still point to wrong fileName) is not good. We can't use it as state is broken.

您的示例存在一个无法克服的问题。你的副作用，这部分代码，不在你的控制范围内:

    // Rename the actual file on the disk (code is omitted)
    // and that is the side effect!

如果是 String，字符串的每个字节都在您的控制之下，因此您可以保证 String 上的方法的纯度。对于您的 File 示例，还涉及一个环境 - 操作系统，该文件是否存在。即使它存在，您的进程也可能无法访问它。您实际上无法重命名文件的原因可能有很多。

IMO 不可能克服这个问题。你周围的世界并不纯粹——你的代码在系统上执行时有很多副作用和可变性。您的磁盘是有状态的，您的 RAM 不是恒定的。即使在 Haskell 中，函数 renameFile::FilePath -> FilePath -> IO () 来自 https://hackage.haskell.org/package/directory-1.3.1.1/docs/System-Directory.html不是理想的纯净 - 在某些情况下可能会导致错误。

但这并不是认为对象无效的理由。正如评论中已经说过的那样，您封装了文件名，而不是文件描述符。因此，您的 File 代表有效的文件名。可能问题更多是关于重命名方法的有效性？

Does it means that object is not truly immutable? And what if we want to work only with true immutable objects with consistent state? We shouldn't rename file on the disk? But how to get the job done when we actually need file to be renamed?

它是不可变的。对该对象的调用 rename 并不纯粹，仅此而已。 不变性 和纯度 是不同的术语。您的对象可能是不可变的并且仍然有副作用，就像您的示例一样。