String的length

Java有一个叫做String的类，可以通过length得到String对象的长度。
现在我要问一个问题，三秒钟给出答案：
这个length是属性（Field）还是方法（Method）。
1、2、3。
你说是属性？
你确认你说的对么？我们可以int n = String.length;但是不可以String.length = n;Why？你见过那个类的某个属性只可读不可写过？
或许你能联想到JavaBean里面的某些规定。确实，有了JavaBean规范，我们可以实现这样一个可读不可写的Property。但问题是String不是一个JavaBean。所以，这里的String是一个不能用Java语言规范给出的类。
C# 的readonly给出了一个比较好的解决方案。但是也有瑕疵，问题在于如果我想修改这个Field，运行时就会阻止这件事情发生，当然，对于 Immutable型的类型来说似乎没有太大的危害，但是mutable型的类型就会有问题了，而且，支持Immutable型类型的语言如果没有GC的支持会非常的丑陋。所以，无论是Java还是C#，解决这个问题的办法不外是一套规范，一套规定如何读取和写入状态的机制。Java用JavaBean解决，C#用Propery解决。看起来很完美。
但是，它们都显得有点重量级，有必要么？C++/CLI甚至规定了更智能的Property方案。节省了大量的无聊的动作和死气沉沉的重复。这是一个明显的改进，但是似乎没有多少人欣赏。
注：实际上C++在很多方面可以说比Java、C#显得更高级，比如说析构的自动调用，这在C#中需要用using来指明，而Java中更是需要用 finally来实现。这导致了它们的哲学（看待世界的方法）的不同，RAII是C++里面自然的和有益的模式，在Java里面蜕化成try finally，更进一步的影响到Java的class的表达能力，不能用来表达资源（非托管型的）！当然，C++的这种包揽也让很多人觉得不爽，觉得控制的粒度不能更细致，以至于（在概念中）可能会影响表达能力。
还是返回到length问题上，这个问题就没有更好的办法了么？
我们从 Eiffel中发现了一种令人称奇的简单的难以置信的方案。那就是：所有的状态特征（Eiffel没有区分属性和方法，统一叫做特征），都是可以读不可以写的，所有的在别的语言中称作方法的那种行为特征分为两类，query和command，其中query跟状态特征一样，不会修改对象的状态，只会返回对象的状态，当然，这可能是通过过滤或者汇总统计之后的状态。而command是用来修改对象状态的那种行为特征。Eiffel甚至特意让没有参数的 query不用()来调用，使得用户没有办法区分query跟状态特征的区别。
这儿似乎让很多人迷惑，这怎么实现信息隐藏！？
哦，是啊，确实，没有办法实现。可是我们要考虑的另一个问题是：我们为什么要实现信息隐藏？
好多人都会立即列举出一大堆理由来，这是他们上软件工程课程的时候记熟了的。可是我要说的是，这一大堆的好处跟信息隐藏没有关系！下面我慢慢的说为什么。
信息存在在计算机空间的目的不是隐藏，而是展现。那为什么我们听熟了听惯了信息隐藏？我想这是一个词语的误用，我们要的是无关信息的隐藏，要的是实现细节的隐藏。细节的无关的信息隐藏对于计算机用户来说是有好处的，但是对于程序员来说，用户认为无关的细节的信息，很有可能恰恰是其关注的焦点信息。从另一个方面来说，我们可以区分出实现细节和用户关注点这两个方面。需要隐藏的是实现细节，而不是大而化之的信息。由于计算机空间内部也有可能是分阶层和等级的，所以，也可以区分出供应者和用户这样的关系，他们也是通过某种定义严格的接口（用户关注点）来隔离和交互的，实现的细节一样被隐藏起来。
说到这儿，很多人还是觉得没有说服力，他们坚持认为应该隐藏数据，而展现方法。怎么说服呢？我们想想Brooks在《人月神话》中怎么说的：给我流程图，我还是不明白，给我数据表格，一切都清楚了。这说明什么？说明人对于信息或者状态的感受能力强过对于操作流程的感受能力，人更能理解的是数据而不是方法。
如果方法是作为一个数据展现的间接层存在，我们也可以说它确实提供了某种程度的灵活性，可是，我们真的需要这种灵活性么？我们的大多数get* set*还不是堕落成为简单的赋值和返回？