有时，操作符重载、友类和多重继承会很好。

然而，我仍然认为这是一个很好的决定。如果Java有运算符重载，那么如果不查看源代码，我们就永远无法确定运算符的含义。目前还没有必要。而且我认为你使用方法而不是操作符重载的例子也是相当可读的。如果你想让事情更清楚，你总是可以在烦人的语句之上添加注释。

// a = b + c
Complex a, b, c; a = b.add(c);

你可能真的会搬起石头砸自己的脚。这就像指针一样，人们会犯愚蠢的错误，所以我们决定把剪刀拿走。

至少我认为这是原因。 反正我是站在你这边的。：）

有时，操作符重载、友类和多重继承会很好。

然而，我仍然认为这是一个很好的决定。如果Java有运算符重载，那么如果不查看源代码，我们就永远无法确定运算符的含义。目前还没有必要。而且我认为你使用方法而不是操作符重载的例子也是相当可读的。如果你想让事情更清楚，你总是可以在烦人的语句之上添加注释。

// a = b + c
Complex a, b, c; a = b.add(c);

我认为这可能是一个有意识的设计选择，迫使开发人员创建的函数的名称清楚地表达了他们的意图。在c++中，开发人员会用与给定操作符的普遍接受性质无关的功能重载操作符，这使得不查看操作符的定义几乎不可能确定一段代码的功能。

Java设计人员认为操作符重载带来的麻烦大于它的价值。就这么简单。

在一种每个对象变量实际上都是引用的语言中，运算符重载具有相当不合逻辑的额外危险——至少对c++程序员是这样。比较c#的==操作符重载和Object的情况。等号和对象。ReferenceEquals(或其他名称)。

假设Java是实现语言，那么a、b和c都是对初始值为null的Complex类型的引用。还假设Complex是不可变的，就像前面提到的BigInteger和类似的不可变BigDecimal一样，我想你是指下面的意思，因为你将引用赋值给从添加b和c返回的Complex，而不是将这个引用与a进行比较。

不是: 复合物a, b, c;A = b + c; 简单得多: 复合物a, b, c;A = b.add(c);