为什么有人坚持不用JavaBean规范的set

Java标准库中，绝对不会出现public int size这样的代码，而一定会一开始就写成：
private int size;public int getSize() { return size; }
让用户一开始就使用getSize，以便有朝一日修改getSize实现时，不破坏向后兼容性。这种public int getSize() { return size; }的惯用手法，就是Java Bean。

现在是2014年，C#、Scala等比Java新的面向对象语言自身就提供了语言特性来实现这些常用需求，所以根本不需要Java Bean这样繁琐的约定。

比如，假如有个Scala版的ScalaIntList：
// 编译成 scala-int-list_1.0.jarobject ScalaIntList {
final case class Node(next: Node, value: Int)}final class ScalaIntList {
var head: ScalaIntList.Node = null
var size: Int = 0}
用户这样用：
val myList = new ScalaIntListprintln(myList.size)
有一天你心血来潮改成这样：
// 编译成 scala-int-list_2.0.jarobject ScalaIntList {
final case class Node(next: Node, value: Int)}final class ScalaIntList {
var head: ScalaIntList.Node = null
final def size: Int = {
var n = head
var i = 0
while (n != null) {
n = n.next
i++
}
i
}}
用户还是照样能用，根本不破坏向后兼容性。所以Scala程序只要不考虑和Java交互，一般就不需要类似Java Bean这样的约定。

顺便说一句，向后兼容性分为源代码级和二进制级，Scala的var或val改为final def的话，无论源代码级的向后兼容性，还是二进制级的向后兼容性，都不遭受破坏。但C#的字段改为属性的话，虽然不破坏源代码级的向后兼容性，但是会破坏二进制级的向后兼容性。这是C#的设计缺陷，导致微软的编码规范不得不禁止使用公有字段。