Java中不可变对象的优点似乎很清楚:
您可以通过使用私有final字段和构造函数注入来支持不变性.
但是,在Java中支持不可变对象的缺点是什么?
即
是否有可能设计一个主要使用不可变对象的大规模系统(深层对象图)?
public class Employee {
private String firstName;
private String lastName;
//private default constructor
private Employee(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public static Employee valueOf (String firstName, String lastName) {
return new Employee(firstName, lastName);
}
}
Run Code Online (Sandbox Code Playgroud)
我非常好奇理解创建这种类的优势.我知道这个类的对象是不可变的,因为初始化后无法更改其变量值.我之前从未做过这样的事情,我真的不明白它的优点.
我想知道从程序员的角度来看,字符串类型是不可变的好处.
技术优势(在编译器/语言方面)可以概括为,如果类型是不可变的,则更容易进行优化.请阅读此处了解相关问题.
另外,在一个可变的字符串类型中,要么你已经内置了线程安全(然后再次,优化更难),或者你必须自己做.在任何情况下,您都可以选择使用具有内置线程安全性的可变字符串类型,因此这不是不可变字符串类型的优势.(同样,更容易进行处理和优化以确保不可变类型的线程安全,但这不是重点.)
但是不可变字符串类型在使用中有什么好处?让某些类型不可变而其他类型不可变的重点是什么?这对我来说似乎很不一致.
在C++中,如果我想要一些字符串是不可变的,我将它作为const引用传递给function(const std::string&).如果我想要一个原始字符串的可更改副本,我将其作为传递std::string.只有当我想让它变得可变时,我才将它作为reference(std::string&)传递.所以我只能选择我想做的事情.我可以用各种可能的类型做到这一点.
在Python或Java中,某些类型是不可变的(大多数都是基本类型和字符串),而其他类型则不是.
在像Haskell这样的纯函数式语言中,一切都是不可变的.
是否有充分理由说明这种不一致是否有意义?或者仅仅是出于技术上的低级原因?
我在一些设计书中读到,不可变类提高了可伸缩性,并且尽可能地编写不可变类.但我认为如此不可改变的阶级会增加对象的扩散.因此,为了提高可伸缩性,使用静态类(具有所有静态方法的类)更好地进行不可变类或更好吗?
Java有字符串池,因为字符串类的对象是不可变的.
但我的问题是 -
制作String POOL需要什么?
为什么字符串类没有像其他类一样保存自己的值?
内部JVM是否需要一些字符串,或者这是性能优势.如果有,怎么样?
我们以这堂课为例:
public class Student{
private String name;
private String id;
public Student(String name, String id){
this.name = name;
this.id = id;
}
... getters and setters for both fields
Run Code Online (Sandbox Code Playgroud)
并将其与此进行比较:
public class Student{
public final String name;
public final String id;
public Student(String name, String id){
this.name = name;
this.id = id;
}
}
Run Code Online (Sandbox Code Playgroud)
我认为不需要访问者.
这会被认为是糟糕的OO设计吗?
我想知道为什么Date结构和对象,比如C#的DateTime和Obj-C的NSDate已经变成了不可变的.
我正在寻找这种设计背后的原因以及使这些信息不可改变的好处,而不仅仅是"因为它们可以"
更新: 似乎有一个类似的问题,我的答案很棒,但专门针对Java,它可以在这里找到:为什么我们需要不可变的类?
这与我的问题的答案相结合,提供了非常丰富的信息
java ×7
immutability ×4
string ×3
c# ×1
c++ ×1
objective-c ×1
oop ×1
pool ×1
python ×1
scalability ×1