怎么自己做网站怎么赚钱,做仿网站公司,萝岗区网站建设推广,基于thinkphp网站制作javabeans我已经最近在博客的想法的JavaBeans™如何可以扩展以减少在Java世界中#xff0c;这被广泛接受的公约设立的膨胀。 该文章在DZone上重新发布#xff0c;并在这里获得了颇具争议的反馈#xff08;例如#xff0c;大多数试图将一些新想法带入Java世界的想法#xf… 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 wasnt 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 arent 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, heres something. Setters that dont set properties, but// modify the underlying file. A.k.a. not-really-setterspublic 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则上述内容将具有以下优点 您的gettersetter和属性具有完全相同的名称以及首字母的大小写。 在代码库中进行文本搜索要容易得多 该getter看起来像Scala这样的语言中的属性本身一样由于使用了语言语法糖“ myBean.myProperty”和“ myBean.myProperty”这些属性等效于表达式。 Getter和setter在字典顺序上紧挨着例如在IDE的“大纲”视图中。 这是有道理的因为财产本身比不采取“获取”和“设置”行动更为有趣。 您无需担心选择“获取”还是“是”。 此外还有一些属性无论如何“ get” /“ is”无论如何都是不合适的例如只要涉及“ has”-“ getHasChildren”或“ isHasChildren” 嗯将其命名为“ hasChildren” “ setHasChildrentrue”吗 不“ hasChildrentrue” 您可以遵循简单的命名规则使用命令式动词来执行动作。 使用第三人称形式的名词形容词或动词访问对象/属性。 该规则已经证明标准约定存在缺陷。 “ 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 –不要通过JAVASQL和JOOQ博客上的JCG合作伙伴 Lukas Eder 向您的API添加Getter 。 翻译自: https://www.javacodegeeks.com/2013/02/bloated-javabeans-dont-add-getters-to-your-api.htmljavabeans
