为什么要在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行为读一个新的，易变的字段在我的子类中声明。因此，最初看起来不可变的你的课程确实不是不可变的。我可以通过这个Mutable对象无论哪里Immutable对象预计，可以做非常糟糕的事情来编码假设对象是真正不可变的。标记基类final可以防止发生这种情况。

希望这会有所帮助！

Answer 2

这限制了其他班级扩展你的班级。

final类不能被其他类扩展。

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

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

Answer 3

如果它不是最终的，那么任何人都可以扩展类并做任何他们喜欢的事情，比如提供setter，隐藏你的私有变量，可变的。

Answer 4

如果你没有完成它我可以扩展它，使它不可变。

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传递给期望不可变的任何类，并且它不会像预期的契约那样工作。

Answer 5

假设下面的类并不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类型的变量不再保证是mmutable。这可能会导致哈希，平等，并发等问题。

Answer 6

与许多人认为相反，使不可变类final是不是必需的。

制定不可变类final的标准参数是如果你不这样做，那么子类可以添加可变性，从而违反超类的契约。班上的客户将承担不变性，但当他们下面发生变化时会感到惊讶。

如果你把这个参数其逻辑的极端，那么所有方法应作出final，否则子类可以覆盖在不符合其超合同的方式方法。有趣的是，大多数Java程序员都认为这很荒谬，但对于不可变类应该是final这个想法有点不错。我怀疑这与Java程序员通常不会完全适应不变性的概念有关，也可能与Java中final关键字的多重含义有关。

符合你的超类的合同是不是可以或应该总是由编译器执行。编译器可以强制执行合同的某些方面（例如：最少的一组方法及其类型签名），但是编译器无法强制实施典型合同的许多部分。

不变性是一个类的合同的一部分。这是从一些东西的人更习惯有点不同，因为它说什么类（及所有子类）不能做的，而我认为大多数Java（一般OOP）的程序员往往会去想合同的涉及什么样的可以做什么，而不是不能做什么。

不变性也影响不仅仅是一个单一的方法更—它会影响整个实例—但这并不比在Java中的工作方式equals和hashCode真的太大的不同。这两种方法在Object中列出了具体的合同。这份合同非常仔细地列出了这些方法不能做的事情。这个合同在子类中更具体。以违反合同的方式覆盖equals或hashCode是非常容易的。事实上，如果你只是忽略了这两种方法中的一种，那么很可能是你违反了合同。所以equals和hashCode已被宣布final在Object以避免这种情况？我认为大多数人会认为他们不应该这样做。同样，没有必要制作不可变类final。

这就是说，你的大部分类，不可变或不可能，可能应该是final。见有效的Java第二版项目17：“继承或禁止它的设计和文档”。

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

Answer 7

不要标记整个班最后。

有一些正确的理由让一个不可变的类可以像其他一些答案中所述的那样扩展，所以将类标记为final并不总是一个好主意。

最好是将您的物业标记为私人物品和最终物品，如果您希望保护“合同”将您的获得者标记为最终物品。

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

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

Answer 8

对于创建不可变类，不强制将该类标记为final。

让我从java类本身的“BigInteger”类中的一个例子是不可变的，但它不是最终的。

实际上，不变性是一个概念，根据哪个对象创建的概念，它不能被修改。

让我们从JVM的角度来看，从JVM的角度来看，所有线程必须共享对象的同一副本，并且在任何线程访问它之前完全构造并且对象的状态在其构建后不会改变。

不变性意味着没有办法哟改变对象的状态，它一旦建立，这是由三个拇指规则，这使得编译器识别类是不可变的实现，有如下几点： -

• 所有非私有字段应该被最终
• 确保有在类没有方法可以改变直接或间接
• 的对象的字段的类中定义的任何对象引用不能从外部修改

欲了解更多信息，请参阅以下网址

http://javaunturnedtopics.blogspot.in/2016/07/can-we-create-immutable-class-without.html

Answer 9

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

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

有了这一点，你需要找到这些问题的答案：

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

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

。另一方面，这将是很难使一个类final它正在使用无处不在后，但它很容易使一个final类非final以后，如果你发现你需要扩展它。

如果您正确使用接口，您可以通过始终使用接口，然后在需要时添加可变实现来避免“我需要使这个可变”问题。

结论：这个答案没有“最佳”解决方案。这取决于你愿意支付哪个价格以及哪些价格。