javabeans_膨胀的JavaBeans –不要在您的API中添加“ Getters”

javabeans

我已经最近在博客的想法的JavaBeans™如何可以扩展以减少在Java世界中，这被广泛接受的公约设立的膨胀。该文章在DZone上重新发布，并在这里获得了颇具争议的反馈（例如，大多数试图将一些新想法带入Java世界的想法）。我想回顾一下我在该文章中提出的想法之一，该想法被较少关注，即：

Getter和Setter的命名

为什么每次要操作对象属性时都必须使用那些those肿的“ get” /“ is”和“ set”前缀？此外，属性的首字母的大小写也发生变化。如果要对所有用法进行区分大小写的搜索

属性，则必须编写一个正则表达式。我特别难以理解为什么我们应该在各处使用吸气剂。 Getters / setters是提供对属性访问的抽象的约定。即，您通常总是在写这样的愚蠢的东西：

public class MyBean {private int myProperty;public int getMyProperty() {return myProperty;}public void setMyProperty(int myProperty) {this.myProperty = myProperty;}
}

好。让我们接受的是，这似乎是我们作为Java开发人员的日常生活，编写了所有这些文章，而不是使用标准的关键字或注释。我说的是标准，而不是Project Lombok等专有的东西。接受生活事实后，让我们看一下java.io.File以获得更多详细信息。对我来说，这是一个很好的例子，其中JavaBean-o-mania™完全错误。为什么？查看此源代码摘录：

public class File {// This is the only relevant internal property. It would be 'final'// if it wasn't set by serialisation magic in readObject()private String path;// Here are some arbitrary actions that you can perform on this file.// Usually, verbs are used as method names for actions. Good:public boolean delete();public void deleteOnExit();public boolean mkdir();public boolean renameTo(File dest);// Now the fun starts!// Here is the obvious 'getter' as understood by JavaBeans™public String getPath();// Here are some additional 'getters' that perform some transformation// on the underlying property, before returning itpublic String getName();public String getParent();public File getParentFile();public String getPath();// But some of these 'transformation-getters' use 'to', rather than// 'get'. Why 'toPath()' but not 'toParentFile()'? How to distinguish// 'toPath()' and 'getPath()'?public Path toPath();public URI toURI();// Here are some 'getters' that aren't really getters, but retrieve// their information from the underlying filepublic long getFreeSpace();public long getTotalSpace();public long getUsableSpace();// But some of the methods qualifying as 'not-really-getters' do not// feature the 'get' action keyword, duh...public long lastModified();public long length();// Now, here's something. 'Setters' that don't set properties, but// modify the underlying file. A.k.a. 'not-really-setters'public boolean setLastModified(long time);public boolean setReadable(boolean readable);public boolean setWritable(boolean writable);// Note, of course, that it gets more confusing when you look at what// seem to be the 'not-really-getters' for the abovepublic long lastModified();public boolean canRead();public boolean canWrite();
}

困惑？是。但是，我们所有人最终都以这种方式做事，一次又一次。 jOOQ没什么不同，尽管将来的版本将解决此问题。

如何改善事情

并非所有的库和API都存在这种缺陷。 Java已经走了很长一段路，并且已经由许多对此主题有不同看法的人编写。此外，Java极具向后兼容性，因此我认为JDK如果是从头开始编写的，那么它仍然不会遭受“ JavaBean-o-mania™”的严重影响。因此，这里有一对夫妇的规则可以遵循在新的API，把事情有点清理：

首先，决定你的API将主要用于弹簧重或JSP / JSF重环境或任何其他环境中使用的JavaBeans™的表达语言，在那里你真的想遵循标准的约定使用。但是，在这种情况下，请严格遵循约定，并且不要命名任何类似这样的信息检索方法：“ File.length（）”。如果您遵循此范式，则所有方法都应以动词开头，绝不能以名词/形容词开头
以上内容仅适用于少数几个库，因此，如果要访问不是属性的对象，则可能永远不要使用“ get”。只需使用属性名称（名词，形容词）。在呼叫站点上，这看起来会更加精简，尤其是如果您的库使用的是Scala之类的语言时。这样，“ File.length（）”是一个不错的选择，就像“ Enum.values（）”一样，而不是“ File.getLength（）”或“ Enum.getValues（）”。
如果要访问属性，则可能也不要使用“ get” /“ set”。 Java可以轻松地将名称空间用于属性/方法名称。只需在getter / setter中使用属性名称本身即可，如下所示：
```
public class MyBean {private int myProperty;public int myProperty() {return myProperty;}public void myProperty(int myProperty) {this.myProperty = myProperty;}
}
```
不过，请再次考虑第一个规则。如果要使用Spring配置bean，则别无选择。但是，如果您不需要Spring，则上述内容将具有以下优点：
- 您的getter，setter和属性具有完全相同的名称（以及首字母的大小写）。在代码库中进行文本搜索要容易得多
- 该getter看起来像Scala这样的语言中的属性本身一样，由于使用了语言语法糖：“ myBean.myProperty（）”和“ myBean.myProperty”，这些属性等效于表达式。
- Getter和setter在字典顺序上紧挨着（例如，在IDE的“大纲”视图中）。这是有道理的，因为财产本身比不采取“获取”和“设置”行动更为有趣。
- 您无需担心选择“获取”还是“是”。此外，还有一些属性，无论如何，“ get” /“ is”无论如何都是不合适的，例如，只要涉及“ has”->“ getHasChildren（）”或“ isHasChildren（）”？嗯，将其命名为“ hasChildren（）”！ “ setHasChildren（true）”吗？不，“ hasChildren（true）”！
- 您可以遵循简单的命名规则：使用命令式动词来执行动作。使用第三人称形式的名词，形容词或动词访问对象/属性。该规则已经证明标准约定存在缺陷。 “ get”是命令形式，而“ is”是第三人称形式。

考虑在设置器中返回“ this”。有些人喜欢方法链：

public MyBean myProperty(int myProperty) {this.myProperty = myProperty;return this;}// The above allows for things likemyBean.myProperty(1).myOtherProperty(2).andThen(3);

或者，返回先前的值，例如：

public int myProperty(int myProperty) {try {return this.myProperty;}finally {this.myProperty = myProperty;}}

下定决心并选择以上任一选项，以确保整个API保持一致。在大多数情况下，方法链接没有实际结果值有用。

无论如何，将“ void”作为返回类型浪费了API范围。具体来说，考虑Java 8的lambda语法用于带/不带返回值的方法（取自Brian Goetz的lambda表示状态）：

// Aaaah, Callables without curly braces nor semi-colons
blocks.filter(b -> b.getColor() == BLUE);// Yuck! Blocks with curly braces and an extra semi-colon!
blocks.forEach(b -> { b.setColor(RED); });// In other words, following the above rules, you probably
// prefer to write:
blocks.filter(b -> b.color() == BLUE).forEach(b -> b.color(RED));

Java 8上线（对于那些维护公共API的人）之后，现在考虑一下这可能是您的API在竞争中的决定性优势。

最后， 一定要使用“获取”和“设置”里你真的想强调语义称为“渐”和“设置”的行动。这包括在以下类型上获取和设置对象：
- 清单
- 地图
- 参考资料
- ThreadLocals
- 期货
- 等等…
在所有这些情况下，“获取”和“设置”都是操作，而不是属性访问。这就是为什么您应该使用诸如“ get”，“ set”，“ put”等动词之类的原因。

摘要

设计API时要有创造力。不要严格遵循JavaBeans™和Spring对整个行业施加的无聊规则。访问对象/属性时，最新的JDK API以及Google / Apache著名的API很少使用“获取”和“设置”。 Java是一种静态的类型安全语言。表达式语言和注入配置是我们日常工作中的例外。因此，我们应该针对我们处理最多的用例优化API。更好的是，如果Spring将他们的思维方式调整为漂亮，精简，漂亮和有趣的API，而不是强迫Java世界使用诸如getter和setter之类的无聊东西来夸大他们的API！

参考： Bloated JavaBeans –不要通过JAVA，SQL和JOOQ博客上的JCG合作伙伴 Lukas Eder 向您的API添加Getter 。