Java中复杂getter的命名约定

我正在阅读这篇MSDN，内容是关于.NET中属性和方法的使用。它指出了为什么以及何时使用属性或方法

属性的用途类似于 字段，这意味着属性应该 计算不复杂或不复杂 产生副作用

否则就应该使用方法

我在问自己如何用Java表达这种差异

---

您的看法是什么？

C#属性基本上是Java的getter和setter合一。如果我需要对一个实例同时使用geter和setter，我总是选择property。在java中，我没有这个选项。

我只是不同意那篇文章所说的。属性是语法糖，否则只需使用字段

getters/properties的要点是封装——用户不知道它是一个字段、您每次计算的内容还是一个随机值

---

这意味着对我来说，Java中不是“数据结构”的每个类都有字段的getter和setter（需要可访问）。如果所有操作都是完全内部的，那么即使对于复杂的实现，

getSomething（）

例外情况是，如果操作非常复杂，可能需要花费大量的时间或资源（例如，从internet下载一些数据）。在这种情况下，我可能会使用一个不同的方法名称-它有点破坏封装，但它是有用和实用的

但是，如果getter有任何可观察到的副作用，我可能不会使用简单的
getSomething（）
约定来避免混淆。也许我会使用
updateAndReturn（）
或
getAndComplexify（）
或
getFromWeb（）
之类的东西

我在问自己如何用Java表达这种差异

只是不要在方法上使用
get
前缀，因为这通常意味着该方法成本低廉（因为getter通常只访问字段，委托给其他getter，或者基于其他getter执行相当简单的计算）。例如，如果类具有此接口：

class Blob {
    long getLength() { ... }
    ByteBuffer getBytes() { ... }
    Sha1Checksum getChecksum() { ... }
}

。。。从
Blob
中获取长度、内容和校验和似乎同样昂贵。如果我们这样做了，那么：

interface Blob {
    long getLength() { ... }
    ByteBuffer getBytes() { ... }
    Sha1Checksum calculateChecksum() { ... }
}

。。。很明显（呃），我们可以期望
calculateChecksum（）
比其他操作更昂贵，因为它的名字表明它不仅仅是为了得到一些东西

在某种程度上，复杂性是一个不应该在接口中看到的实现问题（也许我决定在构建
Blob
时急切地计算校验和？），但在某些情况下，进行区分是有意义的。
“complex getter”听起来像是一个矛盾修饰法，我同意这篇文章。该类的用户应该能够大致理解为什么存在GetXXX（）方法而不是简单属性。我还希望每次调用类的属性时都能得到相同的值（当然，如果没有更改的话）。。。。MSDN的例子显示C++，而不是C代码。C#也有“属性”吗？msdn文章是关于.NET的。C#也有属性，就像C++/CLI一样。