我已經(jīng)最近在博客的想法的JavaBeans?如何可以擴展以減少在Java世界中，這被廣泛接受的公約設(shè)立的膨脹。 該文章在DZone上重新發(fā)布，并在這里獲得了頗具爭議的反饋（例如，大多數(shù)試圖將一些新想法帶入Java世界的想法）。 我想回顧一下我在該文章中遇到的想法之一，該想法得到了較少的關(guān)注，即：

Getter和Setter的命名

為什么每次要操作對象屬性時都必須使用那些those腫的“ get” /“ is”和“ set”前綴？ 此外，屬性的首字母的大小寫也發(fā)生變化。 如果要對所有用法進行區(qū)分大小寫的搜索
屬性，則必須編寫一個正則表達式。 我特別難以理解為什么我們應(yīng)該在各處使用吸氣劑。 Getters / setters是提供對屬性訪問的抽象的約定。 也就是說，您通常總是會一直這樣寫一些愚蠢的事情：

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

好。 讓我們接受的是，這似乎是我們Java開發(fā)人員的日常生活，編寫所有這些文章而不是使用標準關(guān)鍵字或注釋。 我說的是標準，而不是Project Lombok等專有內(nèi)容。 接受生活事實后，讓我們看一下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已經(jīng)走了很長一段路，并且已經(jīng)由許多對此主題有不同看法的人編寫。 此外，Java極具向后兼容性，因此我認為JDK如果是從頭開始編寫的，那么仍然不會遭受“ JavaBean-o-mania?”的嚴重影響。 因此，這里有一對夫婦的規(guī)則可以遵循在新的API，把事情有點清理：

首先，決定你的API將主要用于彈簧重或JSP / JSF重環(huán)境或任何其他環(huán)境中使用的JavaBeans?的表達語言，在那里你真的想遵循標準的約定使用。 但是，在那種情況下，請嚴格遵循約定，并且不要命名任何類似這樣的信息檢索方法：“ File.length（）”。 如果您遵循此范式，則所有方法都應(yīng)以動詞開頭，絕不能以名詞/形容詞開頭

以上內(nèi)容僅適用于少數(shù)幾個庫，因此，如果要訪問不是屬性的對象，則永遠不要使用“ get”。 只需使用屬性名稱（名詞，形容詞）。 在調(diào)用站點上，這看起來會更加精簡，特別是如果您的庫使用的是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;} }

不過，請再次考慮第一個規(guī)則。 如果要使用Spring配置bean，則別無選擇。 但是，如果您不需要Spring，則上述內(nèi)容將具有以下優(yōu)點：

• 您的getter，setter和屬性具有完全相同的名稱（以及首字母的大小寫）。 在代碼庫中進行文本搜索要容易得多
• 在類似Scala的語言中，getter看起來就像屬性本身一樣，由于語言語法糖：“ myBean.myProperty（）”和“ myBean.myProperty”，這些屬性等效于表達式。
• Getter和setter在字典順序上彼此相鄰（例如，在IDE的“大綱”視圖中）。 這是有道理的，因為財產(chǎn)本身比不采取“獲取”和“設(shè)置”行動更為有趣。
• 您不必擔(dān)心選擇“獲取”還是“是”。 此外，還有一些屬性，無論如何，“ get” /“ is”無論如何都是不合適的，例如，只要涉及“ has”->“ getHasChildren（）”或“ isHasChildren（）”？ 嗯，將其命名為“ hasChildren（）”！ “ setHasChildren（true）”嗎？ 不，“ hasChildren（true）”！
• 您可以遵循簡單的命名規(guī)則：使用命令式動詞來執(zhí)行動作。 使用第三人稱形式的名詞，形容詞或動詞訪問對象/屬性。 該規(guī)則已經(jīng)證明標準約定存在缺陷。 “獲取”是命令形式，而“是”是第三人稱形式。

考慮在設(shè)置器中返回“ 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保持一致。 在大多數(shù)情況下，方法鏈接沒有實際結(jié)果值有用。

無論如何，將“ void”作為返回類型浪費了API范圍。 具體來說，考慮Java 8的lambda語法用于有/無返回值的方法（取自Brian Goetz的lambda表示狀態(tài) ）：

// 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的人）之后，現(xiàn)在考慮一下這可能是您的API在競爭中的決定性優(yōu)勢。

最后， 一定要使用“獲取”和“設(shè)置”里你真的想強調(diào)語義稱為“漸”和“設(shè)置”的行動 。 這包括在以下類型上獲取和設(shè)置對象：

• 清單
• 地圖
• 參考文獻
• ThreadLocals
• 期貨
• 等等…

在所有這些情況下，“獲取”和“設(shè)置”都是操作，而不是屬性訪問。 這就是為什么您應(yīng)該使用動詞，例如“ get”，“ set”，“ put”和許多其他動詞的原因。

摘要

設(shè)計API時要有創(chuàng)造力。 不要嚴格遵循JavaBeans?和Spring對整個行業(yè)施加的無聊規(guī)則。 訪問對象/屬性時，最新的JDK API和Google / Apache著名的API很少使用“ get”和“ set”。 Java是一種靜態(tài)的類型安全語言。 表達式語言和注入配置是我們?nèi)粘９ぷ髦械睦狻?因此，我們應(yīng)該針對我們處理最多的用例優(yōu)化API。 更好的是，如果Spring將他們的思維方式調(diào)整為漂亮，精簡，漂亮和有趣的API，而不是強迫Java世界使用諸如getter和setter之類的無聊東西來夸大他們的API！

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

翻譯自: https://www.javacodegeeks.com/2013/02/bloated-javabeans-dont-add-getters-to-your-api.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的膨胀的JavaBeans –不要在您的API中添加“ Getters”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。