为什么要在 Java 中声明一个不可变类 final？

Question

我读到要在 Java 中创建 class immutable，我们应该执行以下操作，

1. 不提供任何setter
2. 将所有字段标记为私有
3. 使课程成为最终课程

为什么需要第 3 步？我为什么要标记课程final？

Answer 1

如果你不标记类final，我可能会突然让你看似不可变的类实际上是可变的。例如，考虑以下代码：

public class Immutable {
     private final int value;

     public Immutable(int value) {
         this.value = value;
     }

     public int getValue() {
         return value;
     }
}

现在，假设我执行以下操作：

public class Mutable extends Immutable {
     private int realValue;

     public Mutable(int value) {
         super(value);

         realValue = value;
     }

     public int getValue() {
         return realValue;
     }
     public void setValue(int newValue) {
         realValue = newValue;
     }

    public static void main(String[] arg){
        Mutable obj = new Mutable(4);
        Immutable immObj = (Immutable)obj;              
        System.out.println(immObj.getValue());
        obj.setValue(8);
        System.out.println(immObj.getValue());
    }
}

请注意，在我的 Mutable 子类中，我已经覆盖了 getValue 的行为，以读取在我的子类中声明的新的可变字段。结果，您的类最初看起来是不可变的，但实际上并不是不可变的。我可以在任何需要Immutable 对象的地方传递这个Mutable 对象，假设对象是真正不可变的，这可能会对代码造成非常糟糕的事情。标记基类final 可以防止这种情况发生。

希望这会有所帮助！

Answer 2

与许多人的看法相反，创建不可变类final 是不需要的。

创建不可变类final 的标准论据是，如果您不这样做，那么子类可以添加可变性，从而违反超类的约定。该类的客户将假定不变性，但当某些东西从他们下面发生变异时会感到惊讶。

如果你把这个论点带到它的逻辑极端，那么所有方法应该被设为final，否则子类可能会以不符合约定的方式覆盖方法它的超类。有趣的是，大多数 Java 程序员都认为这很荒谬，但对不可变类应该是 final 的想法还是很满意的。我怀疑这与 Java 程序员一般不完全接受不变性的概念有关，并且可能与 Java 中 final 关键字的多重含义有关。

编译器不能或不应该始终强制遵守超类的契约。编译器可以强制执行契约的某些方面（例如：最少的一组方法及其类型签名），但编译器无法强制执行典型合约的许多部分。

不变性是类契约的一部分。它与人们更习惯的一些事情有点不同，因为它说明了类（和所有子类）不能做什么，而我认为大多数 Java（通常是 OOP）程序员倾向于将合同视为与类可以做什么，而不是它不能做什么。

不变性不仅影响单个方法——它影响整个实例——但这与Java 中equals 和hashCode 的工作方式并没有太大不同。这两种方法在Object 中有一个特定的合同。这份合同非常仔细地列出了这些方法不能做的事情。该合同在子类中更加具体。很容易以违反合同的方式覆盖equals 或hashCode。事实上，如果您只覆盖这两种方法中的一种而没有另一种，那么您很可能违反了合同。那么equals 和hashCode 是否应该在Object 中声明为final 以避免这种情况？我想大多数人会争辩说他们不应该。同样，没有必要创建不可变类final。

也就是说，您的大多数类，无论是否不可变，可能应该是final。参见Effective Java Second Edition第 17 条：“设计和文档继承，否则禁止它”。

因此，您的第 3 步的正确版本应该是：“使类成为最终的，或者在设计子类时，清楚地记录所有子类必须继续是不可变的。”

Answer 3

不要将整个班级标记为final。

如其他一些答案中所述，允许扩展不可变类是有正当理由的，因此将类标记为最终类并不总是一个好主意。

最好将您的属性标记为私有和最终的，如果您想保护“合同”，请将您的吸气剂标记为最终的。

通过这种方式，您可以允许扩展类（甚至可能通过可变类），但您的类的不可变方面受到保护。属性是私有的，不能被访问，这些属性的 getter 是最终的，不能被覆盖。

任何其他使用不可变类实例的代码都将能够依赖于类的不可变方面，即使它传递的子类在其他方面是可变的。当然，因为它需要你的类的一个实例，它甚至不会知道这些其他方面。

Answer 4

如果它不是最终的，那么任何人都可以扩展该类并做任何他们喜欢的事情，例如提供设置器、隐藏您的私有变量以及基本上使其可变。

Answer 5

这限制了其他类扩展你的类。

final 类不能被其他类扩展。

如果一个类扩展了你想要使其不可变的类，它可能会由于继承原则而改变类的状态。

只需澄清“它可能会改变”。子类可以覆盖超类行为，如使用方法覆盖（如 templatetypedef/Ted Hop 答案）

Answer 6

如果你不把它定为最终的，我可以扩展它并使其不可变。

public class Immutable {
  privat final int val;
  public Immutable(int val) {
    this.val = val;
  }

  public int getVal() {
    return val;
  }
}

public class FakeImmutable extends Immutable {
  privat int val2;
  public FakeImmutable(int val) {
    super(val);
  }

  public int getVal() {
    return val2;
  }

  public void setVal(int val2) {
    this.val2 = val2;
  }
}

现在，我可以将 FakeImmutable 传递给任何期望 Immutable 的类，它不会像预期的合约那样运行。

Answer 7

对于创建不可变类，不必将类标记为final。

让我从标准库本身举一个这样的例子：BigInteger 是不可变的，但它不是 final。

实际上，不变性是一个概念，根据这个概念，对象一旦被创建，就不能被修改。

让我们从 JVM 的角度来思考。从 JVM 的角度来看，这个类的对象应该在任何线程可以访问它之前完全构造，并且对象的状态在构造之后不应该改变。

不可变性意味着一旦创建对象就无法改变它的状态，这是通过三个拇指规则来实现的，这些规则使编译器认识到类是不可变的，它们如下：

• 所有非private 字段应为final
• 确保类中没有可以直接或间接更改对象字段的方法
• 类中定义的任何对象引用都不能从类外部修改

更多信息请参考this URL。

Answer 8

假设您有以下课程：

import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class PaymentImmutable {
    private final Long id;
    private final List<String> details;
    private final Date paymentDate;
    private final String notes;

    public PaymentImmutable (Long id, List<String> details, Date paymentDate, String notes) {
        this.id = id;
        this.notes = notes;
        this.paymentDate = paymentDate == null ? null : new Date(paymentDate.getTime());
        if (details != null) {
            this.details = new ArrayList<String>();

            for(String d : details) {
                this.details.add(d);
            }
        } else {
            this.details = null;
        }
    }

    public Long getId() {
        return this.id;
    }

    public List<String> getDetails() {
        if(this.details != null) {
            List<String> detailsForOutside = new ArrayList<String>();
            for(String d: this.details) {
                detailsForOutside.add(d);
            }
            return detailsForOutside;
        } else {
            return null;
        }
    }

}

然后你扩展它并打破它的不变性。

public class PaymentChild extends PaymentImmutable {
    private List<String> temp;
    public PaymentChild(Long id, List<String> details, Date paymentDate, String notes) {
        super(id, details, paymentDate, notes);
        this.temp = details;
    }

    @Override
    public List<String> getDetails() {
        return temp;
    }
}

我们在这里测试一下：

public class Demo {

    public static void main(String[] args) {
        List<String> details = new ArrayList<>();
        details.add("a");
        details.add("b");
        PaymentImmutable immutableParent = new PaymentImmutable(1L, details, new Date(), "notes");
        PaymentImmutable notImmutableChild = new PaymentChild(1L, details, new Date(), "notes");

        details.add("some value");
        System.out.println(immutableParent.getDetails());
        System.out.println(notImmutableChild.getDetails());
    }
}

输出结果将是：

[a, b]
[a, b, some value]

正如您所见，虽然原始类保持其不变性，但子类可以是可变的。因此，在您的设计中，您无法确定所使用的对象是不可变的，除非您将类设为 final。

Answer 9

假设以下类不是final：

public class Foo {
    private int mThing;
    public Foo(int thing) {
        mThing = thing;
    }
    public int doSomething() { /* doesn't change mThing */ }
}

它显然是不可变的，因为即使是子类也不能修改mThing。但是，子类可以是可变的：

public class Bar extends Foo {
    private int mValue;
    public Bar(int thing, int value) {
        super(thing);
        mValue = value;
    }
    public int getValue() { return mValue; }
    public void setValue(int value) { mValue = value; }
}

现在，可分配给Foo 类型变量的对象不再保证是可变的。这可能会导致哈希、相等、并发等问题。

Answer 10

设计本身没有价值。设计总是用来实现一个目标。这里的目标是什么？我们想减少代码中的意外数量吗？我们想防止错误吗？我们是在盲目遵守规则吗？

另外，设计总是要付出代价的。 Every design that deserves the name means you have a conflict of goals.

考虑到这一点，您需要找到以下问题的答案：

1. 这可以防止多少明显的错误？
2. 这可以防止多少细微的错误？
3. 这会使其他代码更复杂（= 更容易出错）的频率如何？
4. 这会使测试更容易还是更难？
5. 您项目中的开发人员有多优秀？他们需要多少大锤指导？

假设您的团队中有许多初级开发人员。他们会拼命尝试任何愚蠢的事情，只是因为他们还不知道解决问题的好方法。将类设为 final 可以防止错误（很好），但也可以让他们想出“聪明”的解决方案，例如将所有这些类复制到代码中各处的可变类中。

另一方面，在任何地方都使用final 之后，创建一个类将非常困难，但如果您发现需要扩展它，则可以很容易地创建一个非final 类非final .

如果你正确使用接口，你可以避免“我需要使这个可变”的问题，方法是始终使用接口，然后在需要时添加可变实现。

结论：这个答案没有“最佳”解决方案。这取决于你愿意付出什么样的代价以及你必须付出什么样的代价。

Answer 11

equals() 的默认含义与引用相等相同。对于不可变数据类型，这几乎总是错误的。所以你必须重写 equals() 方法，用你自己的实现替换它。 link