Java 中复杂 getter 的命名约定
我正在阅读这篇关于属性和方法的使用的 MSDN 文章 。网。它指出了为什么以及何时使用属性或方法。
属性的用途如下 字段,这意味着属性应该 计算上不复杂或 产生副作用。
否则就应该使用方法。
我问自己如何用 Java 表达这种差异。
你的意见是什么?
I was reading this MSDN article about the usage of properties and methods in .NET. It points out why and when to use properties or methods.
Properties are meant to be used like
fields, meaning that properties should
not be computationally complex or
produce side effects.
Otherwise one should use methods.
I was asking myself how you could express this difference in Java.
What is your opinion?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
只是不要在方法上使用
get
前缀,因为它通常意味着该方法将很便宜(因为 getters 通常只访问字段,委托给其他 getters,或者基于其他 getter 执行相当简单的计算吸气剂)。例如,如果一个类具有以下接口:...从
Blob
获取长度、内容和校验和似乎是同样昂贵的。如果我们这样做,则:...很明显(呃)我们可以预期
calculateChecksum()
比其他操作更昂贵,因为它的名字表明它会做更多的事情只是得到一些东西。在某种程度上,复杂性是一个不应该在接口中看到的实现问题(也许我决定在构建 Blob 时急切地计算校验和?),但有时会出现这种情况做出区分是有道理的。
Just don't use the
get
prefix on the method, as it normally implies that the method will be cheap (as getters usually only access fields, delegate to other getters, or perform fairly simple calculations based on other getters). For example, if a class has this interface:... it would seem that getting the length, contents, and checksum from the
Blob
are equally costly. If we did like this, instead:... it becomes clear(er) that we can expect
calculateChecksum()
to be more expensive than the other operations, as its name says it's going to do more than just get something.To a certain degree, the complexity is an implementation issue that shouldn't be seen in the interface (maybe I decide to calculate the checksum eagerly when the
Blob
is constructed?), but there are occasions where it makes sense to make a distinction.我只是不同意那篇文章所说的。属性是语法糖,否则你只需使用字段。
getter/properties 的要点是封装 - 用户不知道它是否只是一个字段、您每次计算的内容或一个随机值。
这意味着对我来说,Java 中每个不是“数据结构”的类都有其字段的 getter 和 setter(需要可访问)。
I just don't agree with what that article says. Properties are syntactic sugar, otherwise you'd just use fields.
The point of getters/properties is encapsulation - the user does not know whether it's simply a field, something you compute every time or a random value.
This means that for me, every class in Java that is not a "Data Structure" has getters and setters for its fields (that need to be accessible).
这取决于。如果所有操作完全是内部的,那么即使对于复杂的实现, getSomething() 也是可以的 - getters/setters/properties 的重点是封装实现细节并隐藏它们,即使将来它们会发生变化变得复杂。
一个例外是,如果操作非常复杂,可能会花费大量时间或资源(例如从互联网下载一些数据)。在这种情况下,我可能会使用不同的方法名称 - 它有点破坏封装,但它很有用且实用。
但是,如果 getter 有任何可观察到的副作用,我可能不会使用简单的
getSomething()
约定,以避免混淆。也许我会使用updateAndReturn()
或getAndComplexify()
或getFromWeb()
或类似的东西。It depends. If all the operations are completely internal then
getSomething()
is okay even for complex implementation - the whole point of getters/setters/properties is to encapsulate implementation details and hide them, even if in the future they change to be something complex.An exception to this is if the operation is so complex it might significant amount of time or resources (e.g. download some data from the internet). In that case I might use a different method name - it kind of breaks encapsulation but it's useful and practical.
If the getter has any observable side effects, however, I would probably not use the simple
getSomething()
convention, to avoid confusion. Maybe I'll useupdateAndReturn()
orgetAndComplexify()
orgetFromWeb()
or stuff like that.C# Property 基本上是 Java getter 和 setter 的合二为一。如果我需要在一个实例中同时使用 geter 和 setter,我总是选择 property。在java中,我没有这个选项。
C# Property is basically Java getter and setter in one. If I need use both geters and setters for one instance, I always choose property. In java, I don't have this option.