为什么基元的包装类没有 setter？
包装类（如 Integer、Double 等）没有为其内部原始值设置 setter 的原因是什么？
我问这个问题是因为这种功能可以简化微积分，并使 Java 语言更加灵活。
让我举一些例子。
1) 让我们看下面的例子：
Integer x = new Integer(5);
x++;
前面的幕后代码正在执行自动装箱。类似的：
int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Yes that's a new memory allocation
由于这个问题，在 Wrapper 上执行微积分比在普通基元类型上执行要慢。使用 setter 可以更轻松地增加内部值，而无需在堆上分配另一个对象。
2) 另一个困扰我的问题是，在 Java 中不可能像在 C（使用指针）或 C++（指针或引用）中那样编写交换函数。
如果我写 void swap(Integer x, Integer y) 我无法访问内部值，因为，并且我不可能交换这些值。
附： 我的一个朋友建议我应该考虑更大的前景，并从并发性和类型不变性的角度进行思考。
那么你对此有什么解释吗？ 谢谢！
What is the reason why Wrapper classes (like Integer, Double, etc.) don't have a setter for their inner primitive value ?
I am asking this because that kind of functionality would have simplified calculus, and have made the Java language a little more flexible .
Let me give you some examples.
1) Let's take the following example:
Integer x = new Integer(5);
x++;
The previous code behind the scenes is performing autoboxing . Something like:
int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Yes that's a new memory allocation
Because of this problem doing calculus on Wrapper is slower than performing on plain primitive types. With a setter it would've been more easy to increment the inner value, without allocating another object on the heap.
2) Another issue that is bugging me is that is impossible in Java to write a swap function like I can do in C (using pointers) or in C++ (pointers or references).
If i write void swap(Integer x, Integer y) I cannot acces the inner value because, and It is going to be impossible for me to swap the values.
PS:
A friend of mine suggested that i should consider the bigger picture, and think in terms of concurrency and type immutability.
So do you have an explanation for this ?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除非需要将包装类放入集合中，否则通常不会使用它们。如果它们是可变的，那么在集合内部使用并作为哈希表的键就会出现问题。
集合和哈希表需要哈希值始终相同。
Wrapper classes are usually not used unless you need to put them into a collection. If they were mutable it would make problems if used inside sets and as keys for hashtables.
Sets and hashtables need the hash value to be always the same.
1）使用setter，包装器类型将是可变的。不变性在很多方面都是一件好事……线程、代码的一般可理解性等。例如，我个人认为
Calendar和Date是可变的，这是一种耻辱。事实上，您对
x++;的扩展不太正确 - 它使用Integer.valueOf，它并不总是创建一个新值。例如：只有有限范围的
Integer值会像这样被缓存（规范定义了哪些值必须以这种方式运行，但如果 JRE 希望，则允许更广泛的范围）这样做）...但这确实意味着它并不总是创建一个新对象。2）是的，Java没有引用传递。坦率地说，我很少发现这是一个问题。您真正需要多久交换一次变量值？
1) With a setter, the wrapper types would be mutable. Immutability is a good thing in many ways... threading, general understandability of the code etc. Personally I think it's a shame that
CalendarandDateare mutable, for example.In fact, your expansion of
x++;isn't quite right - it usesInteger.valueOfwhich doesn't always create a new value. For example:Only a limited range of
Integervalues are cached like this (the spec defines what values must behave this way, but allows for a wider range if the JRE wishes to do so)... but it does mean that it won't always be creating a new object.2) Yes, Java doesn't have pass by reference. Frankly I very rarely find that to be a problem. How often do you really need to swap the values of variables?
缓存 -128 到 127 范围内的整数需要不可变的整数。考虑下面的代码：
现在如果 Integer 是可变的并且有一个setter，并且有人
这样做也会改变
id的值，并且令很多人惊讶的是：Caching Integers in the range from -128 to 127 requires immutable Integers. Consider the follwoing code:
Now if Integer was mutable and had a setter and someone did
this would change the value of
idtoo and, to a lot of peoples surprise:在 Java 中，字符串和包装类被设计为不可变的，以避免数据的意外更改。您可以查看下面的文章以获取更多信息。
为什么 String 和 Wrapper 类在 java 中是不可变的？
In Java, Strings and wrapper classes are designed as immutable to avoid accidental changes to the data. You can check the below article for further information.
Why Strings and Wrapper classes are immutable in java?